Reply-To header not considered when forwarding mail

[matze]

In the context #1803, we have ensured our contact form mails to be compliant with ​SPF requirements. As a side-effect, forwarding mail received via that channel now seems to broken: One cannot reply to the original sender because the original From address is considered instead of the Reply-To header.

(This description has been taken from e-mail correspondence and #1803, explicit data like original affected mails, incl. header, has not been provided yet.)

We want to search for a mechanism to avoid this behavior; otherwise "people will have to add the original sender explicitly when forwarding mails".

[trev]

@Matze: The reason I didn't open a new ticket: "we want to search for a mechanism" isn't a useful one. Unless you have actual suggestions, this issue is bound to stay marked as "not ready" forever. And I doubt that there are many options. IMHO it's either adding sender's email to email body (might look awkward when people reply and don't remove it) or asking people to specify it manually when forwarding.

[matze]

@trev:

Of course I have some ideas: We could, for example, try to fabricate the message sent by our server to look like a forward of a message sent from the user's mail address. Or try to dig a bit deeper into the protocol, the Original-.*: family of headers looks quite interesting.

Of course this is more a try-and-error approach, but I've read into the RFCs again last night and I believe there are some options worth giving a try. However, I have neither assigned a priority to this ticket, nor have I marked it being ready yet. This is still to be done by you - I have no idea whether you consider this issue important enough right now. Especially since it's more an inconvenience and because we could also just opt for the somehow ugly but quick include-the-address-in-the-body approach. But I hardly doubt that this is considered enough. Still, it's a valid workaround in case none of the other approaches turn out to work.

[matze]

I found one approach that seems to work with manually crafted mails: Creating an *.eml file with the actual message (i.e. the mail form data) and sending it as attachment to a GMail account will actually preserve the info, but it requires a 3rd party GMail app to open them. However, I do not consider this a good solution: Although the result integrates rather seamless for the user, the effort is still way too high. And I really dislike the idea to introduce yet another untrusted party in our communication.

A message crafted to look like a forward in the first place (see my previous post) results in the exact same behavior at GMail as in the current situation. Also, there are a few common, yet mostly non-standard or optional headers that we could try, but GMail seems to not recognize any of the ones I've tested.

Therefore, until GMail either implements *.eml support (won't happen, they ignore user reports for that since years) or introduces another feature we can use to circumvent this issue, we have to stick to the "include-the-address-in-the-body" approach. Although this is not of much elegance, we can easily make it look "not like a dirty hack" by just including On dd/mm/yy hh:mm, "$name" <$mail> wrote: above the message. Most users probably won't even recognize that line due to it's similarity to common mail client generated notes (and there's no need to go the extra mile and prefix the message's lines with >).

[matze]

​https://hg.adblockplus.org/sitescripts/rev/fffc91fada03
​https://hg.adblockplus.org/sitescripts/rev/6339ea8e93c5