Re: [dmarc-discuss] DMARC and null path
Scott Kitterman wrote: >> Am 13.05.2016 um 22:35 schrieb Terry Zink via dmarc-discuss: >>> In Office 365 it would. Others' implementations may vary. >> >> "may or may not" - is that really the intention of DMARC? > > I think RFC 7489, paragraph 3.1.2 is very explicit about this. It is > supposed to pass and if it doesn't it's a bug. It would appear to me that it is that paragraph which acknowledges, explicitly, that this is not so. It says: 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), even though a "pure SPF" implementation according to [SPF] would check that identifier. - Roland ___ 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)
Re: [dmarc-discuss] DMARC and null path
A. Schulze wrote: > Am 13.05.2016 um 22:35 schrieb Terry Zink via dmarc-discuss: >> In Office 365 it would. Others' implementations may vary. > > "may or may not" - is that really the intention of DMARC? That is how DMARC is specified, yes. Intention is a bit harder: - the ideal is that all implementations yield the same results, however - at the time DMARC was publicised it was acknowledged, explicitly, that implementations would be variable (in part because of their dependence upon various underlying implementations of SPF and DKIM, and even more variable integrations with those implementations) but that it was better that each participant made best use of the information that they had available given the limitations of their existing systems, rather than that a much lower bar was set for functionality by requiring uniform behaviour. It's worth bearing in mind the context in which DMARC came into being: a full decade (2003 SPF - 2013 DMARC) had gone into trying to solve the problem with little/no success. Part of the success of DMARC was that it took a more pragmatic approach, including tolerance of variable behaviour by receivers. - Roland ___ 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)
Re: [dmarc-discuss] DMARC and null path
On May 13, 2016 5:20:58 PM EDT, "A. Schulze via dmarc-discuss" wrote: > > >Am 13.05.2016 um 23:10 schrieb Scott Kitterman via dmarc-discuss: >> I think RFC 7489, paragraph 3.1.2 is very explicit about this. It is >supposed to pass and if it doesn't it's a bug. > >you mean "RFC5321.HELO identity is not ... used exept when required to >"fake" an otherwise null reverse-path" ? Yes. It's a not very precise rephrasing of what RFC 4408/7208 say. Scott K ___ 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)
Re: [dmarc-discuss] DMARC and null path
Am 13.05.2016 um 23:10 schrieb Scott Kitterman via dmarc-discuss: I think RFC 7489, paragraph 3.1.2 is very explicit about this. It is supposed to pass and if it doesn't it's a bug. you mean "RFC5321.HELO identity is not ... used exept when required to "fake" an otherwise null reverse-path" ? Andreas ___ 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)
Re: [dmarc-discuss] DMARC and null path
On May 13, 2016 4:56:40 PM EDT, "A. Schulze via dmarc-discuss" wrote: > > >Am 13.05.2016 um 22:35 schrieb Terry Zink via dmarc-discuss: >> In Office 365 it would. Others' implementations may vary. > >"may or may not" - is that really the intention of DMARC? I think RFC 7489, paragraph 3.1.2 is very explicit about this. It is supposed to pass and if it doesn't it's a bug. Scott K ___ 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)
Re: [dmarc-discuss] DMARC and null path
Am 13.05.2016 um 22:35 schrieb Terry Zink via dmarc-discuss: In Office 365 it would. Others' implementations may vary. "may or may not" - is that really the intention of DMARC? Andreas ___ 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)
Re: [dmarc-discuss] DMARC and null path
In Office 365 it would. Others' implementations may vary. -- Terry -Original Message- From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of A. Schulze via dmarc-discuss Sent: Friday, May 13, 2016 1:23 PM To: dmarc-discuss@dmarc.org Subject: Re: [dmarc-discuss] DMARC and null path Am 09.05.2016 um 22:42 schrieb Franck Martin via dmarc-discuss: > RFC7489.MAILFROM is RFC5321.MailFrom if it is not empty, otherwise it is > postmaster@ Hello Franck, does that mean a message could pass DMARC if - it's send from a host sending "mail.example.com" as HELO parameter - have an empty envelope sender - have a header "From: MAILER-DAEMON " - is not DKIM signed at all ??? Andreas ___ 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)
Re: [dmarc-discuss] DMARC and null path
Am 09.05.2016 um 22:42 schrieb Franck Martin via dmarc-discuss: RFC7489.MAILFROM is RFC5321.MailFrom if it is not empty, otherwise it is postmaster@ Hello Franck, does that mean a message could pass DMARC if - it's send from a host sending "mail.example.com" as HELO parameter - have an empty envelope sender - have a header "From: MAILER-DAEMON " - is not DKIM signed at all ??? Andreas ___ 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)
Re: [dmarc-discuss] DMARC and null path
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@ On Mon, May 9, 2016 at 12:50 PM, Maarten Oelering 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@ > 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@ > > 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=@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]
Re: [dmarc-discuss] DMARC and null path
There is a subtle distinction involved here. RFC 7208 (and RFC 4408 before it) don't literally say to use RFC5321.Helo if RFC5321.Mailfrom is null. What they say to to construct a MailFrom using postmas...@rfc5321.helo. That's the difference between RFC5321.Mailfrom and RFC7208/4408.Mailfrom which is what DMARC uses. So technically, DMARC always uses Mailfrom for SPF, but that Mailfrom may have been, in some cases, constructed using Helo. People often say things like "use Helo if Mailfrom is null", but that's shorthand, not precisely what the RFCs say to do. Scott K On Monday, May 09, 2016 09:50:33 PM Maarten Oelering via dmarc-discuss 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@ is used in DMARC context? > > Thanks, > > Maarten > > > On 9 mei 2016, at 19:27, Franck Martin via dmarc-discuss > > 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@ > > > > Hope this helps. > > > > On Mon, May 9, 2016 at 8:17 AM, Terry Zink via dmarc-discuss > > mailto: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 > > <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 <mailto: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 <http://libero.it/> descriptive text "v=spf1 > > ip4:212.48.25.1
Re: [dmarc-discuss] DMARC and null path
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@ is used in DMARC context? Thanks, Maarten > On 9 mei 2016, at 19:27, Franck Martin via dmarc-discuss > 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@ > > Hope this helps. > > On Mon, May 9, 2016 at 8:17 AM, Terry Zink via dmarc-discuss > mailto: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 > <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 <mailto: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 <http://libero.it/> descriptive text "v=spf1 ip4:212.48.25.128/25 > <http://212.48.25.128/25> > ip4:212.48.14.160/27 <http://212.48.14.160/27> > include:srs.bis.na.blackberry.com <http://srs.bis.na.blackberry.com/> > include:srs.bis.eu.blackberry.com <http://srs.bis.eu.blackberry.com/> > include:srs.bis.ap.blackberry.com <http://srs.bis.ap.blackberry.com/> > include:mail.zendesk.com <http://mail.zendesk.com/> -all" > _dmarc.libero.it <http://dmarc.libero.it/> descriptive text "v=DMARC1\; > p=quarantine\; ... > > If 212.48.14.166 sends a mail with null path, > RFC5322.From=@libero.it <http://libero.it/> and *helo=libero.it > <http://libero.it/>*, then SPF thinks to > have a 'MAIL FROM' like "postmas...@libero.it <mailto: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 > <http://smtp-32-i6.italiaonline.it/>[212.48.14.166
Re: [dmarc-discuss] DMARC and null path
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@ 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=@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 p
Re: [dmarc-discuss] DMARC and null path
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=@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] 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=@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)