Microsoft O365 labels nanog potential fraud?

Wed Mar 29 16:24:34 UTC 2017

On Wednesday 29 March 2017 11:12:33 William Herrin wrote:
> On Wed, Mar 29, 2017 at 3:04 AM, DaKnOb <daknob.mac at gmail.com> wrote:
> > Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is
> > concerned. These two systems above try to minimize spoofed e-mail by doing
> > the following:
> > 
> > SPF: Each domain adds a list of IP Addresses that are allowed to send
> > e-mail on their behalf.
> > 
> > DKIM: Each email sent by an "original" mail server is cryptographically
> > signed with a key available, again, in the DNS.
> > 
> > When you send an e-mail to a list, you send it to the mailing list mail
> > server. After that, of the server forwards that e-mail to the recipients,
> > its original address is shown, therefore if Outlook checks for SPF
> > records,
> > that check will fail. An easy way to get around this is for the list to
> > change the From field to something else, like "Mel Beckman via NANOG" and
> > a
> > local email address.
> > 
> > However, when you send that email, it may also be signed with DKIM: any
> > change in subject (say "[NANOG]" is added) or the body (say "You received
> > this email because you subscribed to NANOG" is appended) will also cause
> > that check to fail.
> 
> Hello,
> 
> Both SPF and DKIM are meant to be checked against the domain in the
> envelope sender (SMTP protocol-level return address) which the NANOG list
> sets to nanog-bounces at nanog.org. Checking against the message header "from"
> address is an incorrect implementation which will break essentially all
> mailing lists.
>

This is incomplete.

TL;DR: SPF checks the envelope sender. DKIM doesn't check anything except to 
test that parts of the message haven't been altered. DMARC adds policy to both 
to check them against the header From:. Mailing list software may not work 
with DMARC-reject senders (but Nanog does).

----

SPF checks the envelope sender only. Some Microsoft implementations 
purportedly check the header From:, but they aren't supposed to. Microsoft at 
one time tried to extend SPF to check the header Sender or From via SPF 2.0, 
which didn't catch on. Large mail receivers have also extended SPF checks 
internally in various ways to try to infer whether messages are forged, but 
that's not really SPF.

DKIM doesn't by default check anything except that the headers and body that 
were signed have not been altered since the signature was added. It definitely 
has nothing to do with the envelope sender. There was an ADSP extension to 
DKIM to add policy to the header From: address, but it is superceded by DMARC.

DMARC adds sender policy to both mechanisms. For DMARC to pass, either SPF or 
DKIM must pass and the identifier must be aligned with the header From:. 

So for DMARC+SPF to pass not only must the message come from a source 
authorized by the envelope sender domain, but that domain must be the same 
domain (or parent domain or subdomain) of the header From: address.

For DMARC+DKIM to pass, the DKIM signature must pass and the DKIM signing 
domain must be the same domain (or parent domain or subdomain) of the header 
From: address.

Again, DMARC requires only one or the other mechanism to pass. So messages 
forwarded intact should be OK if they have an aligned DKIM signature.

Mailing lists run by mailing list software usually alter the envelope sender. 
They can therefore create and pass their own SPF policy. However, if the From: 
address is preserved, this will not be an aligned message and will not pass 
DMARC+SPF. And of course if they don't modify the envelope sender, SPF will 
never pass.

Mailing lists often modify either the subject line or message body. This 
breaks the existing DKIM signature. If they preserve the From: address, they 
will therefore never pass DMARC because they can't create an aligned 
signature.

To work with DMARC-reject senders, mailing lists should either:

a) not alter the existing message headers or body, so that pre-existing 
signatures can pass (Nanog works fine, for instance, so I doubt the OP on this 
thread is related).

or

b) replace the From: address, remove existing DKIM signatures, and add their 
own DKIM signature

or

c) reject posts from senders in DMARC-reject domains

Other mail forwarders should not alter signed message headers or the message 
bodies. Microsoft's forwarding in particular tends to break forwarded messages 
by running them through Exchange internally, which likes to rewrite the 
message. This often breaks the DKIM signatures.