Our web application sends email messages to people when someone posts new content. Both sender and recipient have opted into receiving email messages from our application. When preparing such a message, we set
the following SMTP headers:
FROM:
[email protected]
TO:
[email protected]
SENDER:
[email protected]
We chose to use
the author's email address in
the FROM header in an attempt to provide
the best experience for
the recipient; when they see
the message in their mail client,
the author is clear. To avoid
the appearance of spoofing, we added
the SENDER header (with our own company email address) to make it clear that we sent
the message on
the author's behalf. After reading RFCs 822 and 2822, this seems to be an intended use of
the sender header.
Most receiving mail servers seem to handle this well;
the email message is delivered normally (assuming
the recipient mailbox exists, is not over quota, etc). However, when sending a message FROM an address in a domain TO an address in
the same domain, some receiving domains reject
the messages with a response like:
571 incorrect IP - psmtp (in reply to RCPT TO command)
I think this means
the receiving server only saw that
the FROM header address was in its own domain, and that
the message originated from a server it didn't consider authorized to send messages for that domain. In other words,
the receiving server ignored
the SENDER header.
We have a workaround in place:
the webapp keeps a list of such domains that seem to ignore
the SENDER header, and when
the FROM and TO headers are both in such a domain, it sets
the FROM header to our own email address instead. But this list requires maintenance.
Is there a better way to achieve
the desired experience? We'd like to be a "good citizen" of
the net, and all parties involved -- senders and recipients -- want to participate and receive these messages. One alternative is to always use our company email address in
the FROM header, and prepend
the author's name/address to
the subject, but this seems a little clumsy.