For this we need email in each direction to operate with full fidelity - formatting, clever use of headers, attachments, etc.  I know SDP has been (very slowly) improving things in this area, but really I would expect:

1. An email sent to the helpdesk by a requester to be passed through to the techs who have asked for new ticket notifications in such a way as to retain its original formatting, with headers being used to show who it is from (which can be done in a few ways).  If fiddling with the mail headers isn't on the cards, then the requester in the subject line, which the system can do already.

2. An email sent to in response by the technician should behave in the same way, and the requester should receive it in a form that is almost identical to how it was sent (but with the correct reply to address and any additional info/links from the helpdesk).

3. When the technician is the first responder, the helpdesk should assign the ticket to them (which should be a configuration option) unless they include an email command to the contrary.

4. All emails through the helpdesk to requesters should be treated as if the technician entered them via the web interface - so  ticket I respond to should not show us as needing a technician response in the UI.

5. Finally, the email interaction should take pride of place in the web UI, with the initial request details being the first (or last, configurable) message in the thread.  This is how spiceworks does it, and it's very quick to rapidly see what has occurred.

All of the above suits an environment where email is the primary tool for interaction, which is a common approach in my experience.  We can still go into the web interface to add extra ticket info, but with so many tickets coming in out of hours, the above is almost mandatory to operate an efficient helpdesk for us.  The mobile app is very good, and does help, but sometimes you just need to reply to an email quickly and for the helpdesk to do the right thing with that reply.