Contact Form Improvements - 'replyto' and 'from'

While I feel like it would not be too crazy given what EE can already do to implement Contact Email templating for the standard EE contact tag

{exp:email:contact_form}

, I feel like the feature we absolutely can’t do without is developer defined ‘replyto’ and ‘from’ values.

I understand that you can set

replyto="yes"

within the form tag, and the contact form’s ‘from’ value will be used in the ‘replyto’ field (which is totally appropriate, given that many email services will instantly send to spam any email whose ‘from’ field doesn’t match the domain from which it was generated), and in its place, the EE installation’s ‘webmaster’ email address will be used - though it’s worth mentioning that in many cases, this email address will not match the address of the domain.

It seems that when using the reply-to parameter for the standard EE Contact form, there is no way to manually define the value for the contact email’s ‘from’ field, and hence no way to ensure that the contact email is not relegated to spam, in all likelihood 100% of the time.

While using an email address from the same domain as the website as the webmaster email for the EE installation seems to be the only way to guarantee that emails generated from the standard EE contact form aren’t instantly trashed; in some cases, a website is developed on behalf of a client, and managed externally. In such cases, perhaps it’s not appropriate to assign an internal email address from the client’s own web hosting account, which they may be able to gain access to, and in turn super-administrator access to their site (not necessarily desirable).

It seems imperative then that developers should be able to manually define the value for the ‘replyto’ and ‘from’ parameters of the standard EE Contact form for it to not be considered next to useless for delivering emails via modern email services and clients.

Next steps would be the implementation of developer friendly email templating in the EE back end and modern anti-spam /security measures. Though I understand that robust tools to this effect already exist via paid third party EE extensions, it seems reasonable to expect that at least basic versions of these should be available with the standard EE Contact email form, even if not database submission for received entries and so on.