UNSUBSCRIBE ME PLEASE

On 16-04-19 15:00, dmarc-discuss-requ...@dmarc.org wrote:
Send dmarc-discuss mailing list submissions to
        dmarc-discuss@dmarc.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://dmarc.org/mailman/listinfo/dmarc-discuss
or, via email, send a message with subject or body 'help' to
        dmarc-discuss-requ...@dmarc.org

You can reach the person managing the list at
        dmarc-discuss-ow...@dmarc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dmarc-discuss digest..."


Today's Topics:

    1. Failure reports from Microsoft servers due to SPF and DKIM
       both failing for forwarded/resent messages (Geir Waade)
    2. Re: Failure reports from Microsoft servers due to SPF and
       DKIM both failing for forwarded/resent messages (Franck Martin)


----------------------------------------------------------------------

Message: 1
Date: Tue, 19 Apr 2016 11:10:34 +0000
From: Geir Waade <geir.wa...@confirmit.com>
To: "dmarc-discuss@dmarc.org" <dmarc-discuss@dmarc.org>
Subject: [dmarc-discuss] Failure reports from Microsoft servers due to
        SPF and DKIM both failing for forwarded/resent messages
Message-ID:
        <c72df8e67c274644832d0bde5d17c...@co-osl-ex2013.firmglobal.com>
Content-Type: text/plain; charset="us-ascii"

Hello,

We have been ramping up DMARC usage over the last year or so, and recently 
enabled the failure reporting option to allow recipient servers to notify us 
when a message is quarantined or rejected due to a failing policy. We have SPF 
and DKIM in place for our domains and have set the failure policy to fo=0, 
which requires both SPF and DKIM to fail for the DMARC check to fail.

What we've noticed is a potential problem with certain conditions of message 
forwarding, resulting in a bit of failure report flooding. Whenever we send a message 
to someone with a Hotmail/MSN/Outlook.com address, who has configured their account 
to forward email to another address on Microsoft's services (Office365 / Exchange 
hybrid?), we get DMARC failure reports from 
st...@hotmail.com<mailto:st...@hotmail.com>. The headers in the report's 
attached emails show that delivery from our servers to the hotmail server for the 
original address succeeds, with both SPF and DKIM checks passing. However, there's an 
internal delivery exchange of the message between outlook.com / hotmail.com / 
onmicrosoft servers for the new recipient's address, and the recipient's server 
performs a new authentication check on the forwarded message. This fails the SPF 
check, which is to be expected, but should not be enough to fail the message per our 
DMARC policy of 'fo=0'.  However, for some reason!
 i!
  t also fails the DKIM check at this point - possibly due to a modified 
subject or an added anti-spam scan disclaimer? The final recipient's server 
politely adheres to our DMARC policy and rejects/quarantines the message, and 
we get a failure report as a result.

Is there anything we can do as a sender to prevent this from happening, beyond 
relaxing the policy to maybe quarantine less than 100% of failed messages? It 
seems odd that we are getting an abundance of these from Microsoft, but almost 
nothing from other services. Has Microsoft implemented some superfluous auth 
checks in their internal delivery line that fails due to them breaking the DKIM 
signature on a previous step, or is possibly this due to Office365 customer 
setup?

I have several examples of emails with headers showing the odd forwarding path 
these messages take, if you'd be interested in taking a look. Any suggestions 
you can give us would be most welcome.

Best regards,
Geir W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://dmarc.org/pipermail/dmarc-discuss/attachments/20160419/dbc3106a/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 19 Apr 2016 11:30:30 -0700
From: Franck Martin <fmar...@linkedin.com>
To: Geir Waade <geir.wa...@confirmit.com>
Cc: "dmarc-discuss@dmarc.org" <dmarc-discuss@dmarc.org>
Subject: Re: [dmarc-discuss] Failure reports from Microsoft servers
        due to SPF and DKIM both failing for forwarded/resent messages
Message-ID:
        <canyrh9-+mblvz7q9o+2rkwgzaqgkbr1x5-6niw0hrgm+nwr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

MS-Exchange tends to normalize the email (like fix html) before storing it
(in TNEF format) or forwarding it. It is known, and is being addresses.
Several fixes have been in place in office365 (less so for on-premises
systems), but your mileage may vary...

A search through the list archives may help you.

On Tue, Apr 19, 2016 at 4:10 AM, Geir Waade via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

Hello,



We have been ramping up DMARC usage over the last year or so, and recently
enabled the failure reporting option to allow recipient servers to notify
us when a message is quarantined or rejected due to a failing policy. We
have SPF and DKIM in place for our domains and have set the failure policy
to fo=0, which requires both SPF and DKIM to fail for the DMARC check to
fail.



What we've noticed is a potential problem with certain conditions of
message forwarding, resulting in a bit of failure report flooding. Whenever
we send a message to someone with a Hotmail/MSN/Outlook.com address, who
has configured their account to forward email to another address on
Microsoft's services (Office365 / Exchange hybrid?), we get DMARC failure
reports from st...@hotmail.com. The headers in the report's attached
emails show that delivery from our servers to the hotmail server for the
original address succeeds, with both SPF and DKIM checks passing. However,
there's an internal delivery exchange of the message between outlook.com
/ hotmail.com / onmicrosoft servers for the new recipient's address, and
the recipient's server performs a new authentication check on the forwarded
message. This fails the SPF check, which is to be expected, but should not
be enough to fail the message per our DMARC policy of 'fo=0'.  However, for
some reason it also fails the DKIM check at this point ? possibly due to a
modified subject or an added anti-spam scan disclaimer? The final
recipient's server politely adheres to our DMARC policy and
rejects/quarantines the message, and we get a failure report as a result.



Is there anything we can do as a sender to prevent this from happening,
beyond relaxing the policy to maybe quarantine less than 100% of failed
messages? It seems odd that we are getting an abundance of these from
Microsoft, but almost nothing from other services. Has Microsoft
implemented some superfluous auth checks in their internal delivery line
that fails due to them breaking the DKIM signature on a previous step, or
is possibly this due to Office365 customer setup?



I have several examples of emails with headers showing the odd forwarding
path these messages take, if you'd be interested in taking a look. Any
suggestions you can give us would be most welcome.



Best regards,

Geir W

_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well
terms (http://www.dmarc.org/note_well.html)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://dmarc.org/pipermail/dmarc-discuss/attachments/20160419/611f2e95/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)


------------------------------

End of dmarc-discuss Digest, Vol 51, Issue 11
*********************************************



_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Reply via email to