The definition of RFC7489.MAILFROM is not the same as RFC5321.Mailfrom RFC7489.MAILFROM is RFC5321.MailFrom if it is not empty, otherwise it is postmaster@<RFC5321.Helo>
On Mon, May 9, 2016 at 12:50 PM, Maarten Oelering <maar...@postmastery.net> wrote: > Hi Franck, > > You explained this before, but also then I didn’t quite understand. > > First you say there is the SPF check on HELO and on MAILFROM. That I know > and understand. > Then you say DMARC only uses the RFC5321.Mailfrom, but which includes > falls back on RFC5321.Helo. > > But isn’t that the same in practice? The HELO domain is the HELO domain. > Or is the difference that alignment is required when postmaster@<RFC5321.Helo> > is used in DMARC context? > > Thanks, > > Maarten > > On 9 mei 2016, at 19:27, Franck Martin via dmarc-discuss < > dmarc-discuss@dmarc.org> wrote: > > SPF provides 2 results. People get confused because they often think there > is only one. > > The first result is based on the RFC7489.HELO and the second result is > based on the RFC7489.MAILFROM. > > The first result could allow you to close a connection at the RFC5321.Helo > stage, while the second result would allow you to close the connection > after the RFC5321.Mailfrom. In practice both results are integrated in > higher reputation layers... > > DMARC uses only the second result (and identifiers). > > As a side note and as Terry points out, Office 365, only uses the second > results for SPF. Many implementations of SPF use only the second result. > > RFC7489.MAILFROM is defined as RFC5321.MailFrom unless it is empty, in > that case it is postmaster@<RFC5321.Helo> > > Hope this helps. > > On Mon, May 9, 2016 at 8:17 AM, Terry Zink via dmarc-discuss < > dmarc-discuss@dmarc.org> wrote: > >> This is a good point, I'm not sure about how others do it, but in Office >> 365 we compare the 5322.From domain against the domain that was used to >> authenticate SPF. That's the 5321.MailFrom unless it is <>, in which case >> we use the HELO/EHLO domain. That would allow a DMARC pass in the absence >> of a DKIM signature. >> >> -- Terry >> >> -----Original Message----- >> From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf >> Of Sistemisti Posta via dmarc-discuss >> Sent: Monday, May 9, 2016 3:38 AM >> To: dmarc-discuss@dmarc.org >> Subject: [dmarc-discuss] DMARC and null path >> >> Hello DMARC users, >> >> because I'm new in DMARC world I'm trying to understand some details >> before to start with policy implementation. >> >> A detail I would understand is related to mails with null path, or null >> sender address, typically sent by Delivery Status Notifications. >> >> It seems that the only way to pass DMARC with null path is to DKIM sign >> the mails. Is it true? >> >> I ask this because RFC7489 says that exists a condition when DMARC >> considers the null path: >> >> "Note that the RFC5321.HELO identity is not typically used in the >> context of DMARC (except when required to "fake" an otherwise null >> reverse-path)" >> >> And: >> >> "DMARC uses the result of SPF authentication of the MAIL FROM identity. >> Section 2.4 of [SPF] describes MAIL FROM processing for cases in which >> the MAIL command has a null path." >> >> RFC4408 says accordingly: >> >> 'When the reverse-path is null, this document defines the "MAIL FROM" >> identity to be the mailbox composed of the localpart "postmaster" and >> the "HELO" identity (which may or may not have been checked separately >> before).' >> >> So if a mail with null path and HELO domain equal to RFC5322.From passes >> the SPF check, why should DMARC fail? >> >> See at this live example: >> >> libero.it descriptive text "v=spf1 ip4:212.48.25.128/25 >> ip4:212.48.14.160/27 include:srs.bis.na.blackberry.com >> include:srs.bis.eu.blackberry.com include:srs.bis.ap.blackberry.com >> include:mail.zendesk.com -all" >> _dmarc.libero.it descriptive text "v=DMARC1\; p=quarantine\; ... >> >> If 212.48.14.166 sends a mail with null path, >> RFC5322.From=<local>@libero.it and *helo=libero.it*, then SPF thinks to >> have a 'MAIL FROM' like "postmas...@libero.it", passing this result to >> DMARC for alignment with RFC5322.From. (If it passes the helo domain is >> the same) >> >> The result I see: >> ~~~ >> 2016-05-09T09:47:06.481095+02:00 postfix/smtpd[14063]: 3r3Dx63PshzFpVy: >> client=smtp-32-i6.italiaonline.it[212.48.14.166] >> 2016-05-09T09:47:06.636894+02:00 postfix/qmgr[17134]: 3r3Dx63PshzFpVy: >> from=<>, size=308079, nrcpt=x (queue active) >> 2016-05-09T09:47:06.551037+02:00 opendkim[6782]: 3r3Dx63PshzFpVy: >> smtp-32-i6.italiaonline.it [212.48.14.166] not internal >> 2016-05-09T09:47:06.551173+02:00 opendkim[6782]: 3r3Dx63PshzFpVy: not >> authenticated >> 2016-05-09T09:47:06.551960+02:00 opendkim[6782]: 3r3Dx63PshzFpVy: no >> signature data >> 2016-05-09T09:47:06.594831+02:00 opendmarc[9812]: SPF: 3r3Dx63PshzFpVy: >> libero.it pass >> 2016-05-09T09:47:06.595936+02:00 opendmarc[9812]: 3r3Dx63PshzFpVy: >> libero.it pass >> ~~~ >> >> The mail with null path and no DKIM signs passes DMARC. For me this is a >> correct result; isn't it? >> In this particular case we could complain that the client doesn't send >> an helo equal to his hostname, but this is not DMARC related. >> >> >> I would implement DMARC. For DSN sent to Internet by any authorized MTA >> I would declare an SPF record as: >> >> mta.example.com IN TXT "v=spf1 a -all" >> _dmarc.example.com descriptive text "v=DMARC1\; p=reject\;" >> >> Let suppose the above host sends a DSN with null path, >> helo="mta.example.com" and RFC5322.From=postmas...@mta.example.com. >> I expect DMARC passes (in relaxed mode) because SPF passes. >> >> Could you explain me where I'm wrong? >> >> Thank you very much for your help. >> Best Regards >> Marco >> _______________________________________________ >> 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) >> >> _______________________________________________ >> 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) >> > > _______________________________________________ > 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) > > >
_______________________________________________ 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)
