Re: [dmarc-discuss] submission via google / dmarc fail

[Brandon Long via dmarc-discuss]

Sorry, I wasn't on dmarc-discuss for some reason, looking at the archive:

A. Schulze via dmarc-discuss:

>
> I like to point to that open topic without any answer I hoped to get
> from Google
>
> simple setup:
> gmail user send with RFC5322.From *@googlemail.com via google using a
> smartphone.
> the user authenticate as *@gmail.com for submission.
> dkim signing domain: header.d=gmail.com
> spf: gmail.com
> dmarc policy for googlemail.com: quarantine
> result: dmarc fail.
>   - should gmail users no longer use RFC5322.From *@googlemail.com?
>

googlemail.com is definitely "old" and unnecessary, but it shouldn't be
broken.


>   - should gmail users using RFC5322.From *@googlemail.com also
> authenticate the submission as *@googlemail.com?
>

We've been making changes in this area for other things and may have broken
this, and given the state of change, I don't know if it's still broken or
not.  Also, creating a googlemail.com account is complicated, so it's not
easy for me to test myself.

If it doesn't work for login @gmail.com send from @googlemail.com, but does
for login @googemail.com send from @googlemail.com.  I was able to test and
show that login @googlemail.com and send from @gmail.com for my gmail.com
account works fine.

If you can reproduce an issue, please email me with the actual account
information and headers, so I can try to find logs.

Brandon


>   - or is it simply an issue that such messages are not handled
> correctly at google?
> Any clarification is welcome.
> Thanks!
>
> > Hello,
> >
> > last days I wrote to a address 
> > The answer was quarantained as the dmarc check failed.
> >
> > This ist the reply I receved:
> >
> >   Authentication-Results: mail.example.org; dmarc=fail
> > header.from=googlemail.com
> >   Authentication-Results: mail.example.org;
> > dkim=pass (2048-bit key; unprotected) header.d=gmail.com
> > header.i=@gmail.com header.b=gG3f0joi
> >   Authentication-Results: mail.example.org; spf=pass
> > smtp.mailfrom=
> > smtp.helo=mail-wi0-x234.google.com
> >   ...
> >   Received: from [...] (users.submission.client. [public.ip])
> > by smtp.googlemail.com with ESMTPSA id
> > e8sm15252097wiz.0.2015.08.16.23.40.46
> > for <$me>
> > (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256
> bits=128/128);
> > Sun, 16 Aug 2015 23:40:46 -0700 (PDT)
> >   Sender: User 
> >   From: User 
> >   X-Google-Original-From: User  gmail.com>
> >   Message-ID: <55D181EE.8 at gmail.com>
> >   User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0)
> > Gecko/20100101 Icedove/31.7.0
> >   To: ... $me
> >   ...
> >
> > So Sender and X-Google-Original-From are "@gmail.com", but From is
> > "@googlemail.com"
> > No idea if the user did something wrong or only hit a common pitfall.
> > Looks like this user may mix two similar addresses with different
> > domainparts while using them as RFC5322.From or SMTP-Auth Username.
> >
> > Maybe the google people could clarify?
> >
> > Thanks,
> > Andreas


On Sat, May 7, 2016 at 2:16 AM, A. Schulze via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
>
> Am 29.04.2016 um 11:15 schrieb A. Schulze via dmarc-discuss:
>
>> I like to point to that open topic without any answer I hoped to get from
>> Google
>>
>
> nobody could clarify?
>
> 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)
>
___
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-discuss Digest, Vol 51, Issue 11

[Christopher Sweeney via dmarc-discuss]

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: dmarc-discuss@dmarc.org;
Cc:
Subject:Re: [dmarc-discuss] dmarc-discuss Digest, Vol 51, Issue 11

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 +
> From: Geir Waade 
> To: "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:
>
> 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. 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: 
> 
>
> --
>
> Message: 2
> Date: Tue, 19 Apr 2016 11:30:30 -0700
> From: Franck Martin 
> To: Geir Waade 
> Cc: "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:
>
> 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-discus

Re: [dmarc-discuss] dmarc-discuss Digest, Vol 51, Issue 11

[Lynne Mack via dmarc-discuss]

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 +
From: Geir Waade 
To: "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:

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. 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: 


--

Message: 2
Date: Tue, 19 Apr 2016 11:30:30 -0700
From: Franck Martin 
To: Geir Waade 
Cc: "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:

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
me

Re: [dmarc-discuss] DMARC and null path

[Franck Martin via dmarc-discuss]

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]
>> 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 DM

Re: [dmarc-discuss] DMARC and null path

[Scott Kitterman via dmarc-discuss]

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
> > ] 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 

Re: [dmarc-discuss] DMARC and null path

[Maarten Oelering via dmarc-discuss]

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 
> ] 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: 3r3Dx63

Re: [dmarc-discuss] DMARC and null path

[Franck Martin via dmarc-discuss]

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 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 t

Re: [dmarc-discuss] DMARC and null path

[Terry Zink via dmarc-discuss]

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

[Sistemisti Posta via dmarc-discuss]

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)