nanog mailing list archives
Re: Microsoft O365 labels nanog potential fraud?
From: Florian Weimer <fw () deneb enyo de>
Date: Wed, 29 Mar 2017 19:38:29 +0200
* Grant Taylor via NANOG:
On 03/29/2017 04:17 AM, Mel Beckman wrote:Thanks for the very clear explanation. I use DKIM and SPF, but didn't know about this corner case. I'm surprised the SPF, etc architects missed it, or seem to have. In any event, I seem to be getting all the messages.I don't think they did miss it per say. SPF is specifically meant to say where senders are allowed to send from. Mailing lists (in some configurations), forwarders, et. al. (inadvertently) violate this when they re-send the message with the original sender from a not-explicitly-allowed source. Sender Rewriting Scheme is a way that these forwarding services can re-write the SMTP Envelope From address to not run afoul of SPF (et al).
SPF (in its specified form) is very compatible with the way people have been running mailing lists since the mid-to-late 90s because the mailing list specifies itself as the SMTP envelope from address. This has the added benefit of enabling bounce processing. Unfortunately, the envelope from address is used for generating bounces only. Mail clients just show the header. That's why some SPF variants (like the one proposed by Microsoft) apply SPF rules to email headers as well, although this wasn't part of the original SPF spec (because it breaks too much). DKIM was designed from the start to (optionally) break mailing lists, and some mail providers now publish sender domain policies which other mail providers enforce. In effect, this requires pervasive header rewriting (within the mailing list software) before the message can be sent over the mailing list, obfuscating the true sender. It's a very unfortunate situation. The mailing list software could put the original sender address into a new header, and if that header is standardized, mail clients could just display that. But then, certain sender domains would just sign the absence of that header, and we are back to square one. Presumably, we could use a randomized header, so that at least DKIM protocol changes are required, but it is basically an arms race at this point.
Current thread:
- Microsoft O365 labels nanog potential fraud? Mel Beckman (Mar 28)
- Re: Microsoft O365 labels nanog potential fraud? DaKnOb (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Mel Beckman (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Grant Taylor via NANOG (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Leo Bicknell (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Brad Knowles (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Florian Weimer (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Mel Beckman (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? DaKnOb (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? William Herrin (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Mel Beckman (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Grant Taylor via NANOG (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? William Herrin (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? DaKnOb (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Carl Byington (Mar 29)
- RE: Microsoft O365 labels nanog potential fraud? Keith Medcalf (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Alan Hodgson (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? William Herrin (Mar 29)
- Re: Microsoft O365 labels nanog potential fraud? Carl Byington (Mar 29)