Microsoft O365 labels nanog potential fraud?
ahodgson at lists.simkin.ca
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.
> 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
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
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
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).
b) replace the From: address, remove existing DKIM signatures, and add their
own DKIM signature
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.
More information about the NANOG