Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

[Roland Turner via dmarc-discuss]

Jim Popovitch wrote:

> The difficulty I have is exactly as you described.   I received a
> DMARC report that says there is a DKIM failure, but what is not clear
> is whether or not the email was "quite possibly not tested or
> recorded".   That DMARC report is pointless without knowing more.

You should definitely disregard reports that aren't useful to you.

This and some earlier remarks[1] suggest that you're treating DMARC as a 
product or service that you're being invited to purchase and whose vendor is 
therefore motivated to present a product or service that is to your liking - 
and perhaps to improve it to that end - in order to encourage you to purchase. 
That's not what's going on. Partial visibility into receivers' systems is being 
provided, gratis, on an as-is basis (warts and all), in order to allow 
interested domain registrants/owners to take action to tighten their own 
practices and to detect and act against fraudulent uses of their domains. 
Experience to date suggests that what is being provided is appropriate and 
useful to that end. There remains scope for improvement of course, and the fact 
that some receivers' systems don't work in a way that even gathers the 
information that you'd like to receive - let alone report it - is an 
unfortunate fact of real world email systems.

If you're unwilling or unable to process raw feedback, then you should perhaps 
seek out a service provider whose expertise includes dealing with the rough 
edges. There are several; naturally, most cost [quite a bit of] money.

> In it's infancy DMARC was designed for transactional email, not human
> generated content.

This is not correct. Right from the first high-volume domain with a p=reject 
policy (paypal.com) there was a mix of transactional and human-generated email 
with the same domain-name.

>  In those days pundits decreed that DMARC wasn't
> for MLMs and that mailinglists would be whitelisted and treated with
> special care.  As it turns out, the truth is somewhat different.

This is hardly surprising. Pundits should be considered entertainers, not 
oracles.

> Of course, my interest has now turned to
> trying to understand why XYZ determines there is a failure (was it a
> DNS problem?, was there a middle man?, etc.).  The end goal being
> perfect delivery, sans any problems or implication of there being a
> problem needing investigation or effort on my part.

This is fair enough, but as above, you'll do better if you understand the 
limitations of the tools that you're working with. Choices include:

  *   continue assessing DMARC feedback yourself, and accept that it contains 
warts and will never be perfect;
  *   find a vendor who will provide digested feedback which makes all of the 
unpleasantness go away before you see it (this is costly, and the likelihood of 
an exact match between your desires and the services on offer is low, 
however...); or
  *   disregard DMARC feedback entirely.

Agitating to have low level feedback mechanisms not have low-level warts is 
unlikely to succeed, particularly when that feedback is provided gratis.

- Roland

1: 'It is disingenuous, imho, for a receiver to submit a DMARC report to a 
sender if the subtle failures are receiver side or if those reports don't 
contain enough information for the receiver to understand the reason(s) for the 
subtle failure ("give me the RUF or STFU").  :-)'
___
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] Why do I receive RUAs for emails that align?

[Jim Popovitch via dmarc-discuss]

On Wed, Feb 1, 2017 at 5:31 PM, A. Schulze via dmarc-discuss
 wrote:
>
>
> Am 01.02.2017 um 15:11 schrieb Jim Popovitch via dmarc-discuss:
>> I'm running postfix and AFAIK it's only sending 7bit.
>>
>> postfix postscreen
>> postfix smtpD
>> postfix local -> mailman
>> mailman 8bit -> postfix:587 pickup
>
>> postfix cleanup (converts 8bit into 7bit)
>
> this assumption I wouldn't sign blindly. At least I'm not aware it's default 
> behaviour.

Well I am, and I trust the documentation.

> But this seem to be no longer interesting on this list.
> Maybe you like to clarify that on postfix-users...

I didn't come here for postfix support, I only provided the chain to
prove to you that it's not a 8bit vs 7bit issue.

Clearly it's a receiver side issue for a handful of lesser entities as
Google, Hotmail, and Yahoo ascertain the alignment of the same emails
that the handful fail.

-Jim P.
___
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] Why do I receive RUAs for emails that align?

[A. Schulze via dmarc-discuss]

Am 01.02.2017 um 15:11 schrieb Jim Popovitch via dmarc-discuss:
> I'm running postfix and AFAIK it's only sending 7bit.
> 
> postfix postscreen
> postfix smtpD
> postfix local -> mailman
> mailman 8bit -> postfix:587 pickup

> postfix cleanup (converts 8bit into 7bit)
this assumption I wouldn't sign blindly. At least I'm not aware it's default 
behaviour.
But this seem to be no longer interesting on this list.
Maybe you like to clarify that on postfix-users...

> postfix qmgr
> postfix non-smtpD-milters -> opendkim
> postfix qmgr
> postfix smtp
> 
> -Jim P.

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] Why do I receive RUAs for emails that align?

[Peter Gonzalez via dmarc-discuss]

On 2017 Jan 31, 21:14, Jim Popovitch wrote:
> On Tue, Jan 31, 2017 at 5:24 PM, Peter Gonzalez wrote:
>
> > So what exactly did you do to "roll out additional DMARC support" in
> > your Mailman setup?
> 
> Mailman has historically done some funky things with moderator/owner
> notifications.   Depending on your Mailman config, mailman *might*
> send list notifications in ways you might not expect.   I set out last
> year to identify what I saw as bugs in the way Mailman sent
> notifications differently than list traffic.   Those changes are
> tracked here:
> https://code.launchpad.net/~jimpop/mailman/virtual-notices

Does that mean that the DMARC checks from which you are getting failure
reports are being done against "mailing list notifications" and not
against "regular mailing list traffic"? And, if so, that those "mailing
list notifications" are the result of your non-standard setup and not
of vanilla mailman?

> > I don't see why you suspect receivers of your mailing list traffic are
> > doing it wrong when checking it for DMARC. Mailing list traffic is prone
> > to fail DMARC checks in subtle ways.
> 
> It is disingenuous, imho, for a receiver to submit a DMARC report to a
> sender if the subtle failures are receiver side or if those reports
> don't contain enough information for the receiver to understand the
> reason(s) for the subtle failure ("give me the RUF or STFU").  :-)

Yes, but it has not yet been established whether those DMARC check
failures are the result of those receiver's wrong doing.

> I'd bet a few beers that the DKIM failures are due to those companies
> injecting inbound msg headers before processing DMARC checksbut
> without the RUF who really knowsand more importantly why should
> I invest time/effort into tracking that "failure".

It totally depends on you whether you should invest time and effort to
track those "failures". Is deliverability of your mailing list traffic
important to you?

> > Skeptic about what: about those receivers ability to properly check
> > DMARC, or about the usefulness to you of DMARC reporting?
> 
> Skeptic about the usefulness of the reporting.  As I said before, If 1
> receiver shows alignment then my work is complete.

Yes, your work is complete as a MTA operator. No, your work is not
complete as a curator of your mailing list traffic.

> > It seems to me that DMARC reporting is all about statistics, and for
> > statistics to be relevant you have to drown down the noise, and for that
> > you need to have a big enough sample. The samples you provided are very
> > small in the quantity of messages reported, so it could well be that
> > you are seeing noise just now, and that you need a much bigger sample
> > to reap the value of DMARC reporting.
> 
> I disagree.   The larger sample size is still statistically suspect
> due to all the blind spots in the receiver generated data.   Just
> knowing you have a 0.02% DKIM failure is meaningless without knowing
> why.

Well, knowing that some high volume mailing list has a 0.02% DKIM failures
when checking DMARC alignment is quite meaningful compared to having a 50%
DKIM failures in DMARC checks. I would say a 0.02% DKIM failures would be
"statistical noise" for a high volume mailing list, IMHO.

> > For example, see bullet point 3 here to read
> > about the true value of DMARC reporting:
> > https://blogs.msdn.microsoft.com/tzink/2016/09/27/how-we-moved-microsoft-com-to-a-pquarantine-dmarc-record/
> >
> 
> That hurt my eyes to read. :-)   Did you not notice these 2
> conflicting sentences in the first paragraph:
> 
>"In case you hadn???t noticed, Microsoft recently published a DMARC record"
> 
>"This means that any sender transmitting email either into
> Microsoft???s corp mail servers..."
> 
> 
> Hint: Microsoft's DMARC record is NOT used by senders transmitting
> email to Microsoft.

It is implicit on that blog post that Microsoft is checking DMARC
inbound from the Internet -- therefore, if they now start publishing
DMARC p=quarantine then anyone spoofing their domains will have his
spoofed emails landing in the Spam Folder, also when the recipients are
inside Microsoft itself.

Terry Zink is part of the Exchange Online Team for Office 365. I
don't think I have enough fingers to count how many tens of millions
of mailboxes are under his keep (everyone of those being a paying
customer). He knows his stuff.

Bye.

-- 
Peter Gonzalez
___
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] Why do I receive RUAs for emails that align?

[Jim Popovitch via dmarc-discuss]

On Wed, Feb 1, 2017 at 6:50 AM, A. Schulze via dmarc-discuss
 wrote:
>
> Jim Popovitch via dmarc-discuss:
>
>> I'd bet a few beers that the DKIM failures are due to those companies
>> injecting inbound msg headers before processing DMARC checks.
>
>
> an other option: the MX server don't announce 8BITMIME. You send 8-BIT
> and your sending MTA recode down to 7-BIT. DKIM invalidation per design.
> Solution: send 7 BIT only
>

I'm running postfix and AFAIK it's only sending 7bit.

postfix postscreen
postfix smtpD
postfix local -> mailman
mailman 8bit -> postfix:587 pickup
postfix cleanup (converts 8bit into 7bit)
postfix qmgr
postfix non-smtpD-milters -> opendkim
postfix qmgr
postfix smtp

-Jim P.
___
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] Why do I receive RUAs for emails that align?

[A. Schulze via dmarc-discuss]

Jim Popovitch via dmarc-discuss:


I'd bet a few beers that the DKIM failures are due to those companies
injecting inbound msg headers before processing DMARC checks.


an other option: the MX server don't announce 8BITMIME. You send 8-BIT
and your sending MTA recode down to 7-BIT. DKIM invalidation per design.
Solution: send 7 BIT only

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] opendkim-atpszone reproducibility and examples

[Juri Haberland via dmarc-discuss]

SheridanJ West via dmarc-discuss wrote:
> I only have the mismatch problem with opendmarc-reports and thats using
> most of the command line options.
>
> Normal email (port 587) is matched with spf,dkim and dmarc.Please do
> not consider our email servers as mentally retarded in regard to that.
> Hence my posting on a dmarc list.
>
> report emails per the dmarc spec is the last thing left that i struggled
> with.

So your problem seems to be locally generated emails?
Without giving concrete examples of domain names, logfile excerpts and
possibly showing a generated report without any obfuscation it is not possible
to help you as I don't have a crystal ball :)

  Juri


___
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] opendkim-atpszone reproducibility and examples

[SheridanJ West via dmarc-discuss]

I only have the mismatch problem with opendmarc-reports and thats using
most of the command line options.

Normal email (port 587) is matched with spf,dkim and dmarc.Please do
not consider our email servers as mentally retarded in regard to that.
Hence my posting on a dmarc list.

report emails per the dmarc spec is the last thing left that i struggled
with.

As to ATPS1 that is something i am unwilling to test out unless atps01
packs up sooner rather than later this week.



On Wed, Feb 1, 2017 at 8:45 AM, Juri Haberland via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> SheridanJ West via dmarc-discuss wrote:
> > i appear to need atps records for google this is with atps dns text
> records
> > and probably others
> >
> > opendmarc-reports: sent report for gmail.com to
> mailauth-repo...@google.com
> > (2.0.0 Ok: queued as x1)
> >
> > without atps [results i got from last week]
> >
> > postfix/smtp[5820]:
> >  x0: to=,
> > relay=aspmx.l.google.com[74.125.71.26]:25, delay=1.1,
> >  delays=0.13/0.01/0.49/0.43, dsn=5.7.1, status=bounced
> > (host aspmx.l.google.com[74.125.71.26] said: 550-5.7.1
> > Unauthenticated email from example.eu  is not accepted
> > due to 550-5.7.1 domain's DMARC policy.
> > Please contact the administrator of 550-5.7.1 example.eu
> > domain if this was a legitimate mail.
>
> Ok, so without ATPS Google won't take your mail. I suggest to check your
> SPF
> settings - if ATPS (or DKIM) fails, it should at least authenticate via
> SPF.
>
> > I used (appears to work) dns records
> >  _adsp._domainkey.example.eu. "dkim=all atps=y; asl=example.com
> ;"
> > ._atps.example.eu. "v=atps01; d=example.com;"
> > not work (or tried yet) the content made by openmarc-atpszone
> > v=ATPS1; d=example.net
>
> I don't know anything about ATPS, but I fail to see how OpenDMARC is the
> culprit for your problems. You seem to have at least two problems:
> - missing or wrong SPF RR for your sending host
> - some ATPS/DKIM problem (looking at RFC6541 yields that v=ATPS1 is right
> and
> v=atps01 is wrong)
>
>   Juri
>
>
> ___
> 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] opendkim-atpszone reproducibility and examples

[Juri Haberland via dmarc-discuss]

SheridanJ West via dmarc-discuss wrote:
> i appear to need atps records for google this is with atps dns text records
> and probably others
>
> opendmarc-reports: sent report for gmail.com to mailauth-repo...@google.com
> (2.0.0 Ok: queued as x1)
>
> without atps [results i got from last week]
>
> postfix/smtp[5820]:
>  x0: to=,
> relay=aspmx.l.google.com[74.125.71.26]:25, delay=1.1,
>  delays=0.13/0.01/0.49/0.43, dsn=5.7.1, status=bounced
> (host aspmx.l.google.com[74.125.71.26] said: 550-5.7.1
> Unauthenticated email from example.eu  is not accepted
> due to 550-5.7.1 domain's DMARC policy.
> Please contact the administrator of 550-5.7.1 example.eu
> domain if this was a legitimate mail.

Ok, so without ATPS Google won't take your mail. I suggest to check your SPF
settings - if ATPS (or DKIM) fails, it should at least authenticate via SPF.

> I used (appears to work) dns records
>  _adsp._domainkey.example.eu. "dkim=all atps=y; asl=example.com;"
> ._atps.example.eu. "v=atps01; d=example.com;"
> not work (or tried yet) the content made by openmarc-atpszone
> v=ATPS1; d=example.net

I don't know anything about ATPS, but I fail to see how OpenDMARC is the
culprit for your problems. You seem to have at least two problems:
- missing or wrong SPF RR for your sending host
- some ATPS/DKIM problem (looking at RFC6541 yields that v=ATPS1 is right and
v=atps01 is wrong)

  Juri


___
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)