DMARC and From header munging
It occurred to me that one possible variation on From: header munging which wouldn't break any applications depending on this being an actual, working address for a post's author, while still passing DMARC authentication, would be for Mailman to change the From: address to a VERP-like address with the author's address encapsulated within an address @ the list server. Any mail received by the list server for this address would have its address parsed by Mailman and be redirected to the original author's real email address. Would this pass RFC compliance?
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |
Lindsey, I have been following this thread with interest, and relieved that for our list, all posts are moderated. We have determined to repost all messages coming from Yahoo with our moderator's account.
To your question if VERP might be a partial answer, we are using VERP and "Full personalization" so the posters email address is passed through. we are still getting the DMARC error. Here is what came back to my gmail address as a result of a Yahoo post (which I did not receive):
Diagnostic-Code: smtp; 550-5.7.1 Unauthenticated email from yahoo.com is not accepted due to domain's 550-5.7.1 DMARC policy. Please contact administrator of yahoo.com domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1 http://support.google.com/mail/answer/2451690to learn about DMARC 550 5.7.1 initiative. x7si9647998qaj.232 - gsmtp
Terry Earley 801 810-4175 Donate to FitEyes <http://www.fiteyes.com/community/donate-to-fiteyes>
On Thu, Apr 17, 2014 at 12:01 PM, Lindsay Haisley <fmouse@fmp.com> wrote:
It occurred to me that one possible variation on From: header munging which wouldn't break any applications depending on this being an actual, working address for a post's author, while still passing DMARC authentication, would be for Mailman to change the From: address to a VERP-like address with the author's address encapsulated within an address @ the list server. Any mail received by the list server for this address would have its address parsed by Mailman and be redirected to the original author's real email address. Would this pass RFC compliance?
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/terry%40fiteyes.com
On Thu, 2014-04-17 at 12:26 -0600, Terry Earley wrote:
I have been following this thread with interest, and relieved that for our list, all posts are moderated. We have determined to repost all messages coming from Yahoo with our moderator's account.
To your question if VERP might be a partial answer, we are using VERP and "Full personalization" so the posters email address is passed through. we are still getting the DMARC error. Here is what came back to my gmail address as a result of a Yahoo post (which I did not receive):
What I'm suggesting here isn't VERP, as it's optionally implemented in the envelope sender address, but a VERP-like encapsulation of the _author's_ email address into a munged From: address. This is something completely different, but uses the same paradigm for address encapsulation as does the current envelope sender VERP.
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |
On 04/17/2014 11:01 AM, Lindsay Haisley wrote:
It occurred to me that one possible variation on From: header munging which wouldn't break any applications depending on this being an actual, working address for a post's author, while still passing DMARC authentication, would be for Mailman to change the From: address to a VERP-like address with the author's address encapsulated within an address @ the list server. Any mail received by the list server for this address would have its address parsed by Mailman and be redirected to the original author's real email address. Would this pass RFC compliance?
It would probably be RFC compliant as long as the from address reliably worked to send to the author, but there are other problems.
The first that comes to mind is suppose a yahoo.com user replies to a post originally From: another yahoo.com user. There may be DMARC issues with the delivery of this reply from the Mailman server to the original poster.
Maybe not because the forwarding of the reply is a pass-through that *probably* won't break a DKIM signature.
But then what if the original poster had included a Reply-To: to an alternate address. This might result in a reply goint to the original From: instead of the original Reply-To:.
Finally, there is this note from a draft document from the DMARC community:
NOTE: The inclusion of more than one domain in the RFC5322.From field is dangerous. Recent studies by two major senders show that ~95% of all cases in which there is one domain in the RFC5322.From “display name” and different domain in the RFC5322.From “address-spec” are fraudulent. This practice should be discouraged as there are efforts underway to increase “spam scores” within inbound filtering when this is detected.
This implies that the "verp like" encoding should mangle things like "example.com" so they don't look like domain names which could make them difficult to parse.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Thu, 2014-04-17 at 11:29 -0700, Mark Sapiro wrote:
On 04/17/2014 11:01 AM, Lindsay Haisley wrote:
It occurred to me that one possible variation on From: header munging which wouldn't break any applications depending on this being an actual, working address for a post's author, while still passing DMARC authentication, would be for Mailman to change the From: address to a VERP-like address with the author's address encapsulated within an address @ the list server. Any mail received by the list server for this address would have its address parsed by Mailman and be redirected to the original author's real email address. Would this pass RFC compliance?
It would probably be RFC compliant as long as the from address reliably worked to send to the author, but there are other problems.
The first that comes to mind is suppose a yahoo.com user replies to a post originally From: another yahoo.com user. There may be DMARC issues with the delivery of this reply from the Mailman server to the original poster.
Maybe not because the forwarding of the reply is a pass-through that *probably* won't break a DKIM signature.
Well it does come up against the long-standing issue with SPF regarding email redirection, and if an email doesn't come from a mail server supporting DKIM, then there would be an issues in this case.
But then what if the original poster had included a Reply-To: to an alternate address. This might result in a reply goint to the original From: instead of the original Reply-To:.
This is, as I understand it, a MUA issue. Doesn't a reply _always_ go to a Reply-To: address by default? I don't see how munging of the From: address could affect this behavior.
This implies that the "verp like" encoding should mangle things like "example.com" so they don't look like domain names which could make them difficult to parse.
I'm already using AES encryption/decryption in Mailman to put the recipient address into the Resent-Message-ID: header in a form that AOL's brain-dead TOS report system can't redact. This is the same kind of problem. Mangling wouldn't even have to be that sophisticated. ROT13 would probably do.
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |
Lindsay Haisley writes:
Mailman to change the From: address to a VERP-like address with the author's address encapsulated within an address @ the list server. Any mail received by the list server for this address would have its address parsed by Mailman and be redirected to the original author's real email address. Would this pass RFC compliance?
Technically, it probably does. The problem is that Mailman doesn't handle those mails, the MTA does. It would be reasonably easy to set up a filter and have the MTA pass the message to that filter.
It's very ugly, though, especially if for some reason you have no display name to work with.
A bigger problem, as stated what you've done is to set up an open relay. So you would need to either maintain a database of valid addresses forever, or do some crypto trickery so that only valid addresses would be forwarded. The latter would involve key management, etc.
N.B. I read a very similar suggestion somewhere, probably in the DMARC Internet-Draft or in their FAQ.
On Fri, 2014-04-18 at 03:51 +0900, Stephen J. Turnbull wrote:
Lindsay Haisley writes:
Mailman to change the From: address to a VERP-like address with the author's address encapsulated within an address @ the list server. Any mail received by the list server for this address would have its address parsed by Mailman and be redirected to the original author's real email address. Would this pass RFC compliance?
Technically, it probably does. The problem is that Mailman doesn't handle those mails, the MTA does. It would be reasonably easy to set up a filter and have the MTA pass the message to that filter.
We already do this for listname-subscribe, listname-owner, listname-bounces, etc. The addition of another similar name extension should be no problem.
It's very ugly, though, especially if for some reason you have no display name to work with.
Agreed! But the display name is free form and strictly informational. Could this not be the subscriber name of the author, if it's part of the subscription record?
A bigger problem, as stated what you've done is to set up an open relay. So you would need to either maintain a database of valid addresses forever, or do some crypto trickery so that only valid addresses would be forwarded. The latter would involve key management, etc.
This is a good point, so the encapsulated address would have to be obfuscated in some way. Crypto wouldn't be difficult. I've already hacked AES encryption/decryption into Mailman for generating a Resent-Message-ID: header containing the recipient address. I have a single key in mm_cfg.py and as long as it stays the same then addresses will translate. But I see your point. This is putting RFC compliance out an a very long and thin thread. If you change the key, your entire archive of emails becomes theoretically non-compliant, and this is indeed ugly.
N.B. I read a very similar suggestion somewhere, probably in the DMARC Internet-Draft or in their FAQ.
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |
Lindsay Haisley writes:
It's very ugly, though, especially if for some reason you have no display name to work with.
Agreed! But the display name is free form and strictly informational. Could this not be the subscriber name of the author, if it's part of the subscription record?
Sure. But that's putting even more burden on the Mailman server, and in many cases it won't be close to 100%. That's all I'm saying.
participants (4)
-
Lindsay Haisley -
Mark Sapiro -
Stephen J. Turnbull -
Terry Earley