[dmarc-discuss] Use of in DMARC aggregate reports

[Maarten Oelering via dmarc-discuss]

Hi list members,

We see many aggregate reports where  is a subdomain 
which does not publish a DMARC record. The DMARC record is on the organisation 
domain.

The specification (RFC 7489 appendix C) says this should be the domain at which 
the DMARC record was found, not the RFC5322 From domain:
 

   
 
   
   

It’s so widespread it looks like some DMARC reporting software is broken. In 
one of the reports I saw "X-Mailer: opendmarc-reports v1.3.2".

Do others notice this as well? And how do you treat these reports, drop them or 
fix them?

Thanks,
Maarten Oelering
Postmastery






___
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] Yahoo DMARC reports

[Maarten Oelering via dmarc-discuss]

Hi there,

Yahoo (OAuth) is sending DMARC reports with a space after the “end” timestamp:


  1538524800 
  1538611199 
   

This breaks strict parsers which expect an integer, following the schema In RFC 
7489:

   
 
   
   
 
   

It has been like this for years, and probably many have found a workaround or 
use relaxed parsers. But I think it should be fixed.

Anyone from OAuth in this group who can push for a fix?

Thanks,
Maarten Oelering
Postmastery


___
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 reports from Trustwave SEG

[Maarten Oelering via dmarc-discuss]

Hi,

Is anyone from Trustwave on this list?

Their SEG software don’t know how to spell "Content-Type”. It’s spelled without 
dash:

=c5c709ca-bc35-4c5e-aca0-da12cbc9280f
ContentType: application/gzip;
name=“receiver.co.uk!sender.com!1523433708!1523522202!4344.xml.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=“receiver.co.uk!sender.com!1523433708!1523522202!4344.xml.gz"

I noticed this already a year ago. It would be nice if they fixed it. It’s 
already a challenge to handle the many variations in mime encoding and 
compression.

Thanks,
Maarten Oelering
Postmastery

___
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 reports from TrustWave SEG

[Maarten Oelering via dmarc-discuss]

Is anyone from Trustwave SEG on this list? They should check the spelling of 
Content-Type in their DMARC reports:

=6777a7f7-be29-40d4-ba25-6d03af8ce8d1
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This is a DMARC report generated by Trustwave SEG.

=6777a7f7-be29-40d4-ba25-6d03af8ce8d1
ContentType: application/gzip;
name="marshal.com!waternet.nl!1488397305!1489051603!281.xml.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="marshal.com!waternet.nl!1488397305!1489051603!281.xml.gz"

Thanks,

Maarten Oelering
Postmastery


___
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

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

Re: [dmarc-discuss] Multiple SPF results in report

[Maarten Oelering via dmarc-discuss]

Do you mean that in the XML you see 6  elements in one  
element? Or do you mean you see 6 different  domains in the your reports?

Maarten Oelering
Postmastery

> On 4 apr. 2016, at 09:05, Nick via dmarc-discuss  
> wrote:
> 
> I received a DMARC report with multiple SPF results. I wonder how this is 
> possible as I only have one SPF record for my domain defined. In one report I 
> got 6 SPF results.
> 
> The only thing I could think of is some automatic forwarding service changing 
> the return path header. Are there more usecases possible how this can happen?
> 
> Thanks
> Nick
> ___
> 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 configuration when using spam solution in Front of O365

[Maarten Oelering via dmarc-discuss]

If you can share the full email header of a test mail as it is received,
that would help. For example from a Gmail account. Based on that it's easy
to check SPF/DKIM validation, alignment, etc. You can also use a service
like emailaudit.com to check all DMARC prerequisites.

Maarten
Postmastery

On Friday, 1 April 2016, Duggan, Anita via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Good Morning,
>
>
>
> We are in the process of setting up DKIM and DMARC for our domains.   Our
> inbound and outbound email flow goes from O365 to a spam provider and then
> to the internet and vice versa.   We have implemented DKIM / DMARC on O365,
> using the 2 cname records, and have DMARC set to take no action at this
> time.  However, I am unclear what action needs to be taken to address that
> the last hop before our mail goes out to the internet is our spam
> provider.  Any assistance would be greatly appreciated
>
>
>
>
>
> Thanks,
>
>
>
> *ADuggan*
>
> adug...@rbi.com 
>
>
>
> The information contained in this message may be proprietary, confidential
> or trade secret and may be legally privileged. The message is intended
> solely for the addressee(s). If you are not the intended recipient, you are
> hereby notified that any use, dissemination, disclosure or reproduction is
> strictly prohibited and may be a violation of law. If you are not the
> intended recipient, please contact the sender by return e-mail and destroy
> all copies of the original message.
>
> Les renseignements contenus dans ce message peuvent être de propriété
> exclusive, de nature privilégiée, confidentiels ou relever du secret
> commercial. Ce message est strictement réservé à l’usage de son ou ses
> destinataires. Si vous n’êtes pas le destinataire prévu, vous êtes, par la
> présente, informé que toute utilisation, distribution, divulgation ou
> reproduction est strictement interdite et peut constituer une infraction à
> la loi. Si vous n’êtes pas le destinataire prévu, veuillez communiquer avec
> l’expéditeur par courriel et détruire tous les exemplaires du message
> original.
>
___
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)