Re: [dmarc-discuss] DSN from microsoftonline.com

2017-12-27 Thread A. Schulze via dmarc-discuss


Terry Zink via dmarc-discuss:


I'm not sure I follow what the problem is.

AFAIK, we send NDRs from postmaster@ and then use the customer's  
default domain. Most customers have this set to *.onmicrosoft.com  
which they get when they sign up for the service, and then some flip  
it to their custom domain. All domains are signed with their  
*.onmicrosoft.com by default (after an initial delay), regardless of  
whether or not they have configured DKIM.


Hello Terry,

my initial "problem" are DSN messages from a domain with p=quarantine  
that don't authenticate by DMARC.


as you say you apply DKIM signatures with *.onmicrosoft.com. For  
customers with defaults also the RFC5322.From should be  
postmaster@*.onmicrosoft.com. That's fine.


But I see some DSN with  
RFC5322.From=
And these can't be authenticated by DKIM and SPF fail also because the  
EHLO is *.outbound.protection.outlook.com


When you say "NDR" do you mean "non delivery report" ?
I see DSN, positive "delivery status notification". It's technically  
the same but maybe handled different somewhere...


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] DSN from microsoftonline.com

2017-12-22 Thread Terry Zink via dmarc-discuss
I'm not sure I follow what the problem is.

AFAIK, we send NDRs from postmaster@ and then use the customer's default 
domain. Most customers have this set to *.onmicrosoft.com which they get when 
they sign up for the service, and then some flip it to their custom domain. All 
domains are signed with their *.onmicrosoft.com by default (after an initial 
delay), regardless of whether or not they have configured DKIM.

From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of A. 
Schulze via dmarc-discuss
Sent: Thursday, December 21, 2017 5:25 AM
To: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] DSN from microsoftonline.com



Am 21.12.2017 um 02:03 schrieb Roland Turner via dmarc-discuss:

Hello Roland,

> Have you explored whether the organisations whose DSNs are failing DMARC also 
> have the rest of their email failing DMARC?
at least I didn't have seen messages from those organisations with non empty 
RFC5231.MailFrom

> The use of the ${customer}.onmicrosoft.com domain to sign is consistent with 
> domains for which DKIM signing hasn't been turned on. (It could also be a 
> DSN-handling bug of course.)
Ah!
maybe Terry can have a look at this!

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] DSN from microsoftonline.com

2017-12-21 Thread A. Schulze via dmarc-discuss


Am 21.12.2017 um 02:03 schrieb Roland Turner via dmarc-discuss:

Hello Roland,

> Have you explored whether the organisations whose DSNs are failing DMARC also 
> have the rest of their email failing DMARC?
at least I didn't have seen messages from those organisations with non empty 
RFC5231.MailFrom

> The use of the ${customer}.onmicrosoft.com domain to sign is consistent with 
> domains for which DKIM signing hasn't been turned on. (It could also be a 
> DSN-handling bug of course.)
Ah!
maybe Terry can have a look at this!

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] DSN from microsoftonline.com

2017-12-21 Thread A. Schulze via dmarc-discuss


Am 21.12.2017 um 01:37 schrieb Brandon Long via dmarc-discuss:
> For bounces (ie, empty MAIL FROM), the EHLO argument is used for the SPF 
> lookup, so it is technically possible for there to be a valid SPF record.

Hello Brandon,

I wasn't aware of that. But https://tools.ietf.org/html/rfc7489#section-3.1 is 
pretty clear:

while [SPF] can authenticate either the domain that appears in the
RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/HELO 
domain, or both

and here are the requested rDNS / HELO informations:
   
RFC5321.MailFrom <>
RFC5322.From 
DKIM-Signature   d=${customer}.onmicrosoft.com

client   
mail-db5eur01hn0241.outbound.protection.outlook.com[104.47.2.241]
ehlo EUR01-DB5-obe.outbound.protection.outlook.com
or
client   
mail-ve1eur01hn0213.outbound.protection.outlook.com[104.47.1.213]
ehlo EUR01-VE1-obe.outbound.protection.outlook.com

> That said, I wouldn't bet on it.  I know there's still an open bug to create 
> the DNS SPF records for our EHLO hostnames at Google, it was just never a 
> high priority.  Plus, it wouldn't really help the DMARC case because our 
> DSN's come from @googlemail.com  for some reason I was 
> never clear on but our EHLO hostnames are google.com .

looks like there is the same challenge as on your side :-)

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] DSN from microsoftonline.com

2017-12-21 Thread Roland Turner via dmarc-discuss

On 21/12/17 05:43, A. Schulze via dmarc-discuss wrote


Am 20.12.2017 um 18:44 schrieb Roland Turner via dmarc-discuss:

What HELO/EHLO hostname is being presented?

I'm out of office for the next days and have no access to that data.
 From what I remember it's the hostname of the sending system, a rDNS related 
to Microsoft.

Why do you think, the EHLO is important?

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] DSN from microsoftonline.com

2017-12-20 Thread Roland Turner via dmarc-discuss

On 21/12/17 05:43, A. Schulze via dmarc-discuss wrote:


Am 20.12.2017 um 18:44 schrieb Roland Turner via dmarc-discuss:

What HELO/EHLO hostname is being presented?

I'm out of office for the next days and have no access to that data.
 From what I remember it's the hostname of the sending system, a rDNS related 
to Microsoft.

Why do you think, the EHLO is important?


SPF tests both:

 * the domain in the email address provided in MAIL FROM; and
 * the hostname provided in HELO/EHLO

in part to deal intelligently with the empty return paths used in 
automated notifications of non-delivery, delivery-status, and delivery.


I doubt that this will solve your problem, but note that your assertion 
that SPF could never been aligned wasn't supported by the information 
that you quoted.


The actual answer to your problem will therefore turn on DKIM. Have you 
explored whether the organisations whose DSNs are failing DMARC also 
have the rest of their email failing DMARC? The use of the 
${customer}.onmicrosoft.com domain to sign is consistent with domains 
for which DKIM signing hasn't been turned on. (It could also be a 
DSN-handling bug of course.)


- 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] DSN from microsoftonline.com

2017-12-20 Thread Brandon Long via dmarc-discuss
On Wed, Dec 20, 2017 at 1:48 PM A. Schulze via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
>
> Am 20.12.2017 um 18:44 schrieb Roland Turner via dmarc-discuss:
> > What HELO/EHLO hostname is being presented?
>
> I'm out of office for the next days and have no access to that data.
> From what I remember it's the hostname of the sending system, a rDNS
> related to Microsoft.
>
> Why do you think, the EHLO is important?
>

For bounces (ie, empty MAIL FROM), the EHLO argument is used for the SPF
lookup, so it is technically possible for there to be a valid SPF record.

That said, I wouldn't bet on it.  I know there's still an open bug to
create the DNS SPF records for our EHLO hostnames at Google, it was just
never a high priority.  Plus, it wouldn't really help the DMARC case
because our DSN's come from @googlemail.com for some reason I was never
clear on but our EHLO hostnames are google.com.

Brandon
___
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] DSN from microsoftonline.com

2017-12-20 Thread A. Schulze via dmarc-discuss


Am 20.12.2017 um 18:44 schrieb Roland Turner via dmarc-discuss:
> What HELO/EHLO hostname is being presented?

I'm out of office for the next days and have no access to that data.
>From what I remember it's the hostname of the sending system, a rDNS related 
>to Microsoft.

Why do you think, the EHLO is important?

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] DSN from microsoftonline.com

2017-12-20 Thread Roland Turner via dmarc-discuss

What HELO/EHLO hostname is being presented?

- Roland



On 20/12/17 21:14, A. Schulze via dmarc-discuss wrote:


Hello,

we use to send a portion of messages requesting delivery status 
notification on success.
In general DSN messages tend to not pass DMARC very often, but as we 
request DSN on success explicit

we monitor them.

Now I noticed a pattern on DSN sent from Microsoft.

RFC5321.MailFrom <>
RFC5322.From 
DKIM-Signature   d=${customer}.onmicrosoft.com

SPF could never be aligned and DKIM isn't aligned.

$ opendmarc-check microsoftonline.com
DMARC record for microsoftonline.com:
    Sample percentage: 100
    DKIM alignment: relaxed
    SPF alignment: relaxed
    Domain policy: none
    Subdomain policy: quarantine
    Aggregate report URIs:
    mailto:d...@rua.agari.com
    Failure report URIs:
    mailto:d...@ruf.agari.com

Any subdomain use p=quarantine but any DSN systematically fail.
Is this intentional?

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)

[dmarc-discuss] DSN from microsoftonline.com

2017-12-20 Thread A. Schulze via dmarc-discuss


Hello,

we use to send a portion of messages requesting delivery status  
notification on success.
In general DSN messages tend to not pass DMARC very often, but as we  
request DSN on success explicit

we monitor them.

Now I noticed a pattern on DSN sent from Microsoft.

RFC5321.MailFrom <>
RFC5322.From 
DKIM-Signature   d=${customer}.onmicrosoft.com

SPF could never be aligned and DKIM isn't aligned.

$ opendmarc-check microsoftonline.com
DMARC record for microsoftonline.com:
Sample percentage: 100
DKIM alignment: relaxed
SPF alignment: relaxed
Domain policy: none
Subdomain policy: quarantine
Aggregate report URIs:
mailto:d...@rua.agari.com
Failure report URIs:
mailto:d...@ruf.agari.com

Any subdomain use p=quarantine but any DSN systematically fail.
Is this intentional?

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)