Unsubscribe yourself with the link at the bottom of every email where you originally subscribed.
Sent From My Sprint Phone. ------ Original message------ From: Lynne Mack via dmarc-discuss Date: Mon, May 9, 2016 6:17 PM To: [email protected]; Cc: Subject:Re: [dmarc-discuss] dmarc-discuss Digest, Vol 51, Issue 11 UNSUBSCRIBE ME PLEASE On 16-04-19 15:00, [email protected] wrote: > Send dmarc-discuss mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [dmarc-discuss] Failure reports from Microsoft servers due to > SPF and DKIM both failing for forwarded/resent messages > Message-ID: > <[email protected]> > 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 > [email protected]<mailto:[email protected]>. 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 <[email protected]> > To: Geir Waade <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 < > [email protected]> 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 [email protected]. 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] 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)
_______________________________________________ dmarc-discuss mailing list [email protected] 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)
