Potential issues using member's "from" address and the "sender" header

A major component of our application sends email to members on behalf of other members. Currentl开发者_Go百科y we set the "From" address to our system address and use a "Reply-to" header with the member's address. The issue is that replies from some email clients (and auto-replies/bounces) don't respect the "Reply-to" header so get sent to our system address, effectively sending them to a black hole. We're considering setting the "From" address to our member's address, and the "Sender" address to our system address. It appears this way would pass SPF and Sender-ID checks.

Are there any reasons not to switch to this method? Are there any other potential issues?

---

Here are way more details than you probably need:

When the application was first developed, we just changed the "from" address to be that of the sending member as that was the common practice at the time (this was many years ago). We later changed that to have the "from" address be the member's name and our address, i.e.,

From: "Mary Smith" <messages@company.example>

With a "reply-to" header set to the member's address:

Reply-To: "Mary Smith" <marysmith@memberisp.example>

This helped with messages being mis-categorized as spam. As SPF became more popular, we added an additional header that would work in conjunction with our SPF records:

Sender: <messages@company.example>

Things work OK, but it turns out that, in practice, some email clients and most MTA's don't respect the "Reply-To" header. Because of this, many members send messages to messages@company.example instead of the desired member.

So, I started envisioning various schemes to add data about the sender to the email headers or encode it in the "from" email address so that we could process the response and redirect appropriately. For example,

From: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

where the string after "messages" is a hash representing Mary Smith's member in our system. Of course, that path could lead to a lot of pain as we need to develop MTA functionality for our system address. I was looking again at the SPF documentation and found this page interesting:

http://www.openspf.org/Best_Practices/Webgenerated

They show two examples, that of evite.com and that of egreetings.com. Basically, evite.com is doing it the way we're doing it. The egreetings.com example uses the member's from address with an added "Sender" header.

So the question is, are there any potential issues with using the egreetings method of the member's from address with a sender header? That would eliminate the replies that bad clients send to the system address. I don't believe that it solves the bounce/vacation/whitelist issue since those often send to the MAIL FROM even if Return Path is specified.

---

So I decided to answer my own question since no one else responded. Perhaps others will find this entry when searching.

What we're finally doing is this:

Set the From header to the user's actual email address.

From: "Mary Smith" <marysmith@memberisp.example>

Use a Sender header with the system wide email address.

Sender: <messages@company.example>

Finally, the actual sender that shows up in the server supplied MAIL FROM/Return Path header is set with a unique identifier, i.e.,

Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

That allows a program running at messages@company.example to intercept those auto replies and forward them onto the person they were originally intended to reach. Most real email clients will reply to the From: header. I haven't seen problems from blackberry users nor others responding to the system account.

After a month or so in production, we've had fewer issues with this than the previous method we were using.

The Sender header adds a small note in Microsoft Outlook clients about "On Behalf Of" but that's appropriate for our usage. There haven't been any issues with SPF in common clients/mta with this setup (Gmail, Yahoo, SpamAssassin, etc.)

Update: In April 2014, Yahoo and AOL changed their DMARC settings to drop these kinds of messages without notice. (They switched to p=reject; see https://wordtothewise.com/2014/04/brief-dmarc-primer/ for more information.) Our solution was to special case those domains, since the needed functionality still works with the vast majority of domains.

IF ISP MATCHES YAHOO OR AOL

From: "Mary Smith" <messages+ca54bb7482ace09f@company.example>
Reply-To: "Mary Smith" <marysmith@memberisp.example>
Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

ELSE

From: "Mary Smith" <marysmith@memberisp.example>
Sender: <messages@company.example>
Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

END