You're looking at the wrong things. Those are the message headers. You should be looking at the SMTP envelope. (How the envelope is specified depends from how, exactly, your application is submitting mail to the mail system. On many systems the envelope is specified by command-line arguments to the mail submission utility program.) Depending from exactly when in the protocol transaction it decides to issue that 571 response, the SMTP Relay server may not have even seen the message headers at all.
The response text is saying that the administrator of that particular SMTP Relay server you are talking to has restricted what you can put in the SMTP envelope. It appears to be complaining about the recipient part of the envelope. But it may be deferring validation of the envelope sender until specification of the first recipient, so it may be complaining about the sender.
Note that the envelope sender is where delivery status messages are sent, and you'll not want to have those directed to random people around the world. (Aside from the fact that many people don't like this, it makes no sense for delivery status messages for your mail to be returned to anyone but you.) Specify yourself as the envelope sender.
It is wrong to require MX
resource records, by the way. An SMTP Relay server can be located by A
and AAAA
resource records in the absence of any MX
resource records. See RFC 5321 § 5.1.
There are many reasons why the Header and Envelope From addresses may not match. Most concern automated processes sending mail, where delivery issues need to be reported to an address that is not representative of who sent the mail, or who it was sent on behalf of, or who should be replied to. Mailing lists as you've pointed out are a good example.
The main reason why a message sent from a user's mail client might have differing from addresses is forwarded mail. The mail content should then be reasonably faithful to the original, but in case of delivery errors, those should be reported to the user who forwarded the email, not the original sender.
Besides the SMTP header, There are a variety of MIME headers that various programs use to try to distinguish between the original sender, and intermediate sender, and/or the preferred address to report errors to.Eg Reply-To, Sender, Originally-From, Errors-To, etc, etc, Each with different semantics. Some of these have standards support, while many more do not, but may be in use anyway. The way various mail programs behave in practice varies considerably.
Whether a manner of addressing mail is advisable is a different matter from whether it is "legitimate" as you ask. If you're considering legitimacy here in terms of something like policy for handling potential spam, then no, I don't think you'll be able to make a simple distinction in this way.
Have a think though about DKIM signing of email, and SPF authentication of mail servers for email domains. If you're sending much mail, it may be important to be able to authenticate your mail in these ways, and that may have implications for the addressing of mail From headers, as you can only authenticate mail related to domains for which you have authority.
--
Extended on request:
A MIME 'Reply-To' header directs a MUA (Mail User Agent, usually a person's mail client) to send replies to a different address, instead of the MIME 'From' address. This is not used by an MTA (Mail Transport Agent) for things like errors.
Usually an MTA would use the SMTP Envelope 'MAIL From' address to send errors to. IT can be overriden with a MIME 'Errors-To' header, which is an MTA instruction. Not all MTAs will honor it, so it's an inferior mechanism to setting the SMTP Envelope address, but there are many circumstances where it may be possible to set MIME Headers in a message, but not the SMTP Envelope From address. Eg software running in a shared hosting environment may find itself in this situation.
'Sender' is much more ambiguous as an instruction to software agents, but indicates who or what sent the email where that is distinct from the From address which is more like who the mail was sent on behalf of. Eg when you fill out an on-line mail-your-politician form, it would be very appropriate for the resulting email to use your mail in the From header, but have a Sender address related to the organisation who set up the form.
'Originally-From' is used by some MUA software when forwarding mail, with the forwarder's address being used for the 'From' header. Other MUAs will Leave the From address alone, and use a 'Resent-From' header. Whether MUAs recieving these various headers emails interpret the headers usefully, or even display them is quite variable. When replying to a mail that has been forwarded to you, who should the reply go to by default? Maybe best to set that 'Reply-To' header?
The behavior of MUAs is variable, aand poorly defined, although it does seem to be improving over time. By contrast, the semantics of the Envelope are much more defined. There's typically been a strong position that MTAs should never concern themselves with the MIME headers, but as MTAs are increasingly held responsible for mail content (eg see SPF and the emerging DMARC standards), there's pressure for the clarity of that position to be degraded. Long-standing mechanisms like Errors-To have also conflicted with the notion of MTAs not looking at header content, which is part of why those mechanisms have always been inconsistently applied. Philosophies of software authors vary.
You might find it useful to look over https://www.rfc-editor.org/rfc/rfc4021#section-2 , but remember that the actual practices of the multitude of mail software out there varies in ways which are not necessarily standards blessed.
It's fine to try to come up with a clear philosophy of how you think mail should be used, but don't expect that everyone else will do things how you think they should.
Best Answer
Excellent question. I've just spent several hours researching the same thing.
I had previously deployed numerous websites that use Option C for email forms (mainly out of naivety), but we are experiencing an increasing number of delivery issues. Email providers are gradually tightening up on things. For example Yahoo recently changed their DMARC policy to ask receivers to reject all emails
From: ____@yahoo.com
without a valid DKIM signature. Receiving SMTP servers that follow DMARC (which includes Gmail, and probably Hotmail/Outlook.com and Yahoo) will hard bounce these messages. eBay and Paypal have similar strict policies I believe, in an attempt to reduce phishing. Unfortunately specifying a "Sender" header does not help.(I wonder how Gmail works around this when sending "From" a Yahoo alias?!)
Option A would be a better option if you know the "From" email does not have a strict DMARC policy (you could possibly confirm this via a simple DNS query).
Despite being the least visually-appealing, Option D is really the safest and is what I will recommend for most of our future projects. It's worth noting that PayPal previously used Option A, but have now switched to Option D.
To gain additional credibility and increased chance of delivery, I would look at implementing SPF and/or DKIM. These and other things are mentioned in Google's Bulk Sender Guidelines which I found helpful.