Microsoft O365 labels nanog potential fraud?

Wed Mar 29 17:38:29 UTC 2017

* 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.