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

[Peter Gonzalez via dmarc-discuss]

On 2017 Feb  8, 10:08, Jim Popovitch via dmarc-discuss wrote:
> On Wed, Feb 8, 2017 at 9:45 AM, John Levine via dmarc-discuss wrote:
> 
> > But perhaps this discussion can be over now.
> 
> Not with false and misleading statements/assumptions.

Oh, come on!

https://xkcd.com/386/


-- 
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 Feb 9, 2017 01:36, "Roland Turner via dmarc-discuss" <
dmarc-discuss@dmarc.org> wrote:

On 02/08/2017 10:45 PM, John Levine via dmarc-discuss wrote (after Jim
Popovitch wrote):

They have an obligation, to everyone, to get it right, irregardless of
>> sender preferences.
>>
> I have to say that it's amusing that someone apparently believes that
> every DMARC installation in the world should rewrite their code,
> breaking backward compatibility, merely because he can't be bothered
> to learn how to use the analysis tools that everyone else uses.
>

I would hazard a guess that he hasn't grasped that this is the corollary of
the obligation that he is asserting that senders of reports have to him.
More importantly, it would appear that - despite my coming at the question
from multiple directions in the hope of finding common ground on this point
- he really does believe that random third parties have this obligation to
him. This being the case, agreement on how to address his initial concern
would appear to be impossible to achieve.


But perhaps this discussion can be over now.
>

I'm being politely prodded off-list along these lines and, sadly, am
inclined to agree. Apologies to all for not disengaging sooner.

- Roland



The only proper way to end this discussion is with a mental image: Statler
and Waldorf sitting in a balcony box, high above the stage.

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

[Roland Turner via dmarc-discuss]

Jim Popovitch wrote:

 You should definitely disregard reports that aren't useful to you.
>>>
>>> I'd actually prefer to work with the sender in order to fully
>>> understand the differences between what they see and what larger
>>> receivers see.
>>
>> Given that feedback is provided on an as-is basis, and particularly given
>> your assertion immediately below, your preferences are presumably not
>> relevant to this question.
>
> Thank you Mr. Manners.

I don't follow. Are you conceding that receivers sending reports may not find 
your preferences terribly important?

> That's just your opinion, man.   For the good of the industry they do
> have an obligation to get it right.

The self-entitled act - Dudeist or otherwise - tends to be an ineffective 
motivator for others, even when it doesn't engender outright resistance.

>>> Let me reiterate something I've said a few times now.   I only need 1
>>> accurate report, that attests to alignment, to know that my work is
>>> complete.   The rest are chaff, and I've got no interest in reading
>>> reports on chaff.
>>
>> This claim is difficult to reconcile with the fact that you continue to look
>> at smaller receivers' feedback and then complain about their failure to
>> provide with accurate data. If this claim were correct, then
>> your observed behaviour would be that you'd check against Yahoo! and/or
>> Gmail and then not even look at other receivers' reports. This quite clearly
>> does not describe the situation correctly and therefore invalidates your
>> claim.
>
> You are just reading and seeing what you want to see.   It's pretty
> clear that I don't need to look at all reports, all the time; but that
> I do, on occasion, look at all reports to see how things are going.

I'm merely reading what you wrote (and indeed, quoting it). Expanding my 
earlier comment below, you:
- switch position to the narrow interest of only caring about enough feedback 
to test your code when your obligation argument is refuted,
- switch back to your self-entitled "obligation" position when your narrow 
interest claim is refuted by citing your own behaviour,
- and then start the cycle again.

It's clear that you do care about the broader issues despite your repeated 
claims to the contrary, the difficulty is that you respond to this by trying to 
make it other people's obligation to serve you. There is a lengthy track record 
in addressing email abuse of this approach not being effective. Paraphrasing 
(and inverting) John Levine's oft-repeated observation about funding the costs 
of solving impersonation/domain-abuse problems: receivers have a budget of $0 
to solve MLMs' problems.

> 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.
>>>
>>> I'm not going to dig up the history (esp at this hour of the AM before
>>> the coffee is done brewing) but it's there in one of the early specs.
>>> I've highlighted it before on this list.
>>
>> It is you who raised the history in support of your argument. If you're
>> conceding that DMARC was originally designed/intended/implemented for use
>> with individual email then this is moot. If not, then I'd happy to address
>> any actual quote from relevant source material that appears to support your
>> argument.
>
> It's the first hit when you Google for "dmarc transactional"... should
> I put that in a lmgtfy format for you?  :-)

Noting Google's tendency to personalise results, posting the link to the page 
and quoting the text would have been sensible. I'm assuming that you mean, from 
https://dmarc.org/wiki/FAQ :

dmarc.org> DMARC technology is best-suited for transactional emails and 
semi-transactional emails. Users that suddenly cannot reach the other members 
of a mailing list ...

This is an obviously correct statement about the current situation; were it not 
so, ARC would not exist. Your incorrect statement (still quoted above) was 
about what DMARC was designed to do, not about its present status.

>> You appear to have multiple conflicting intentions (receivers are/are-not
>> obliged to you, you want to examine only-one/all receivers' reports, etc.).
>
> The world is multi-faceted, I apologize if the number of angles in
> this thread has exceeded your capabilities.

Facets and angles are fine, it's your repeated self-contradiction that I was 
addressing.

> To reiterate, I want to only look at necessary reports, but reserve
> the right to, on occasion, dive deeper to try and route out and
> further understand misc issues (you call them warts).

As with your preferences, your rights do not appear to be at issue here. That 
you actually "dive deeper" is indeed part of my argument above.

>> Paying someone to report on suspect data is the opposite of what I proposed
>> 

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

[Jim Popovitch via dmarc-discuss]

On Fri, Feb 3, 2017 at 1:50 AM, Roland Turner via dmarc-discuss
 wrote:
> Jim Popovitch wrote:
>
>
>>> You should definitely disregard reports that aren't useful to you.
>>
>> I'd actually prefer to work with the sender in order to fully
>> understand the differences between what they see and what larger
>> receivers see.
>
> Given that feedback is provided on an as-is basis, and particularly given
> your assertion immediately below, your preferences are presumably not
> relevant to this question.

Thank you Mr. Manners.

>
>>> 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 -
>>
>> Absolutely not.   There is nothing I've said to remotely indicate
>> that, even that footnoted comment doesn't suggest I feel others have
>> an obligation to meet my demands.   They do, however, have an
>> obligation to send accurate data, and if they don't that is
>> disingenuous.
>
> Setting aside the mismatch between my observation and your response, you
> contradict yourself. Receivers who are providing you with feedback, on a
> gratis and as-is basis, obviously don't have the obligations that you are
> asserting.


That's just your opinion, man.   For the good of the industry they do
have an obligation to get it right.

>
>> Let me reiterate something I've said a few times now.   I only need 1
>> accurate report, that attests to alignment, to know that my work is
>> complete.   The rest are chaff, and I've got no interest in reading
>> reports on chaff.
>
> This claim is difficult to reconcile with the fact that you continue to look
> at smaller receivers' feedback and then complain about their failure to
> provide with accurate data. If this claim were correct, then
> your observed behaviour would be that you'd check against Yahoo! and/or
> Gmail and then not even look at other receivers' reports. This quite clearly
> does not describe the situation correctly and therefore invalidates your
> claim.

You are just reading and seeing what you want to see.   It's pretty
clear that I don't need to look at all reports, all the time; but that
I do, on occasion, look at all reports to see how things are going.

 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.
>>
>> I'm not going to dig up the history (esp at this hour of the AM before
>> the coffee is done brewing) but it's there in one of the early specs.
>> I've highlighted it before on this list.
>
> It is you who raised the history in support of your argument. If you're
> conceding that DMARC was originally designed/intended/implemented for use
> with individual email then this is moot. If not, then I'd happy to address
> any actual quote from relevant source material that appears to support your
> argument.

It's the first hit when you Google for "dmarc transactional"... should
I put that in a lmgtfy format for you?  :-)

>>> 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.
>>
>> I think I've already made my intention well known, and I would never
>> pay someone to report on suspect data.
>
> You appear to have multiple conflicting intentions (receivers are/are-not
> obliged to you, you want to examine only-one/all receivers' reports, etc.).

The world is multi-faceted, I apologize if the number of angles in
this thread has exceeded your capabilities.

To reiterate, I want to only look at necessary reports, but reserve
the right to, on occasion, dive deeper to try and route out and
further understand misc issues (you call them warts).

> Paying someone to report on suspect data is the opposite of what I proposed
> and you quoted.

I'm pretty sure your words advocated paying monies to someone else to
look at the totality of my DMARC reports.

>>> Agitating to have low level feedback mechanisms not have low-level warts
>>> is
>>> unlikely to succeed, particularly when that feedback is provided gratis.
>>
>> Thank goodness other solid ideas didn't struggle with those fiefdom
>> issues.   Imagine if FBLs and ARF had been subjected to this
>> pay-to-play model you're advocating.
>
> I don't advocate a pay-to-play model, I merely point it out as the
> appropriate option for someone who wants real-world warts removed for him,
> rather than deal with them himself. The 

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

[Roland Turner via dmarc-discuss]

Jim Popovitch wrote:


>> You should definitely disregard reports that aren't useful to you.
>
> I'd actually prefer to work with the sender in order to fully
> understand the differences between what they see and what larger
> receivers see.

Given that feedback is provided on an as-is basis, and particularly given your 
assertion immediately below, your preferences are presumably not relevant to 
this question.

>> 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 -
>
> Absolutely not.   There is nothing I've said to remotely indicate
> that, even that footnoted comment doesn't suggest I feel others have
> an obligation to meet my demands.   They do, however, have an
> obligation to send accurate data, and if they don't that is
> disingenuous.

Setting aside the mismatch between my observation and your response, you 
contradict yourself. Receivers who are providing you with feedback, on a gratis 
and as-is basis, obviously don't have the obligations that you are asserting.

> Let me reiterate something I've said a few times now.   I only need 1
> accurate report, that attests to alignment, to know that my work is
> complete.   The rest are chaff, and I've got no interest in reading
> reports on chaff.

This claim is difficult to reconcile with the fact that you continue to look at 
smaller receivers' feedback and then complain about their failure to provide 
with accurate data. If this claim were correct, then
your observed behaviour would be that you'd check against Yahoo! and/or Gmail 
and then not even look at other receivers' reports. This quite clearly does not 
describe the situation correctly and therefore invalidates your claim.

>>> 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.
>
> I'm not going to dig up the history (esp at this hour of the AM before
> the coffee is done brewing) but it's there in one of the early specs.
> I've highlighted it before on this list.

It is you who raised the history in support of your argument. If you're 
conceding that DMARC was originally designed/intended/implemented for use with 
individual email then this is moot. If not, then I'd happy to address any 
actual quote from relevant source material that appears to support your 
argument.

>> 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.
>
> I think I've already made my intention well known, and I would never
> pay someone to report on suspect data.

You appear to have multiple conflicting intentions (receivers are/are-not 
obliged to you, you want to examine only-one/all receivers' reports, etc.).

Paying someone to report on suspect data is the opposite of what I proposed and 
you quoted.

>> Agitating to have low level feedback mechanisms not have low-level warts is
>> unlikely to succeed, particularly when that feedback is provided gratis.
>
> Thank goodness other solid ideas didn't struggle with those fiefdom
> issues.   Imagine if FBLs and ARF had been subjected to this
> pay-to-play model you're advocating.

I don't advocate a pay-to-play model, I merely point it out as the appropriate 
option for someone who wants real-world warts removed for him, rather than deal 
with them himself. The same is true for FBLs, SMTP, hosting, datacentres, 
technology generally. Your options are always some combination of build (and 
deal with the warts), buy (and pay someone else to deal with most/all of the 
warts), or desist.

Like processing DMARC feedback, processing FBLs requires dealing with 
real-world warts, particularly with non-uniform redaction policies. DMARC 
feedback happens to expose more complicated differences in how different 
receivers process email (like skipping DKIM verification when SPF has already 
passed) and so is perhaps more work to consume usefully, but the broad 
situation is the same: here is what our real-world system is capable of 
reporting, you are welcome to receive it if it is useful to you.

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

[Jim Popovitch via dmarc-discuss]

On Thu, Feb 2, 2017 at 1:58 AM, Roland Turner via dmarc-discuss
 wrote:
> 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.

I'd actually prefer to work with the sender in order to fully
understand the differences between what they see and what larger
receivers see.

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

Absolutely not.   There is nothing I've said to remotely indicate
that, even that footnoted comment doesn't suggest I feel others have
an obligation to meet my demands.   They do, however, have an
obligation to send accurate data, and if they don't that is
disingenuous.

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

Let me reiterate something I've said a few times now.   I only need 1
accurate report, that attests to alignment, to know that my work is
complete.   The rest are chaff, and I've got no interest in reading
reports on chaff.

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

I'm not going to dig up the history (esp at this hour of the AM before
the coffee is done brewing) but it's there in one of the early specs.
I've highlighted it before on this list.


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

Some of those pundits are still reading this.

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

I think I've already made my intention well known, and I would never
pay someone to report on suspect data.

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

Thank goodness other solid ideas didn't struggle with those fiefdom
issues.   Imagine if FBLs and ARF had been subjected to this
pay-to-play model you're advocating.

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

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

[Jim Popovitch via dmarc-discuss]

On Tue, Jan 31, 2017 at 11:14 PM, Roland Turner via dmarc-discuss
 wrote:
> Jim Popovitch wrote:
>
>
>> I rolled out additional DMARC support for Mailman (outbound alignment)
>> recently, and to be honest I'm not yet convinced that all receivers
>> have a clue when verifying alignment...
>
> Can you explain what difficulty you're describing here? From the examples
> that you linked I saw messages that had SPF passes, meaning that the DKIM
> result was not important (and quite possibly not tested or recorded).

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.

>> so it makes it much more
>> difficult, for me, to trust the data.So... imho it's a waste of
>> time/effort building an archive of suspect data until faith can be
>> established in what is reported.
>
> You certainly shouldn't spend time and effort on this if you're not deriving
> value from it. The idea of trusting the data is an unusual one in a DMARC
> context though. One of the things that DMARC reporting does is to expose the
> variability and complexity of real-world email systems, meaning that the
> data often requires human interpretation and even guesswork. DMARC reports
> should be treated as indicative rather than trustworthy, in any typical
> sense of that word. It is certainly to be taken for granted that there is
> incomplete and/or erroneous data in the reports.
>
> It occurs to me that you've not spelled out clearly what you're attempting
> to achieve with DMARC (or I missed your doing so). Doing so might surface an
> incorrect expectation on your part that might allow your difficulties to be
> resolved in one step.

In it's infancy DMARC was designed for transactional email, not human
generated content.   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.  For
starters, a LOT of what a MLM does *is* transactional, so DMARC is a
perfect fit for at least that part of it.  In particular Mailman sends
a lot of transactional notifications (subscription notices, posting
notices, password reminders, etc.) and it never really mattered (until
now) that Mailman would have a Sender and From with different domains
(sitelist vs mailing list).   In order to improve longterm
deliverabilty it was (to me) imperative to fix the Mailman domain
alignment issues wrt notifications.   Now that that is coded, and
DMARC RRs published, it's working perfectly, save for the few "false
positive" failure reports. 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.

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

[Jim Popovitch via dmarc-discuss]

On Tue, Jan 31, 2017 at 5:24 PM, Peter Gonzalez via dmarc-discuss
 wrote:
> On 2017 Jan 31, 05:59, Jim Popovitch wrote:
>> On Sat, Jan 28, 2017 at 1:49 AM, Dave Warren wrote:
>> > On Fri, Jan 27, 2017, at 04:23, Jim Popovitch wrote:
>> >
>> >> But what can you do about it?  What is the "value" of having that
>> >> information, and what is the "cost" of capturing it?
>> >
>> > To me, the value of these reports is pre-deployment, by carefully
>> > reviewing the reports you can identify any legitimate sources of mail
>> > which are not properly signed and aligned.
>>
>> I rolled out additional DMARC support for Mailman (outbound alignment)
>> recently, and to be honest I'm not yet convinced that all receivers
>> have a clue when verifying alignment... so it makes it much more
>> difficult, for me, to trust the data.So... imho it's a waste of
>> time/effort building an archive of suspect data until faith can be
>> established in what is reported.
>
> 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


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

>> Here's a few examples for the same email:
>>
>> Hotmail gets it right:
>> http://domainmail.org/dmarc-reports/hotmail.com%21netcoolusers.org%211485698400%211485784800.xml
>>
>> ItaliaOnline gets it right:
>> http://domainmail.org/dmarc-reports/italiaonline.it%21netcoolusers.org%211485778386%211485778386.xml
>>
>> VirginMedia gets it wrong:
>> http://domainmail.org/dmarc-reports/virginmedia.co.uk%21netcoolusers.org%211485734404%211485820804.xml
>>
>> CSP-Net gets it wrong:
>> http://domainmail.org/dmarc-reports/bechu-vir0001.csp-net.ch%21netcoolusers.org%211485730804%211485817204.xml
>
> I see in those samples you provide that DKIM is failing for some
> messages. Could it be that some subscriber(s) to your mailing list has
> set up some kind of subject-tagging and ulterior forwarding when he
> receives your mailing list messages?

Great question, but you should ask Virgin Media or CSP-Net.   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".

>> So it's 50/50 for the same small sample of list traffic.   Do I care,
>> sure!   If someone from Virgin Media or CSP-Net wants to explain the
>> failures (or send me the RUFs that I already ask for) then I am all
>> ears.   Until then, I remain a skeptic.  ;-)
>
> 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.

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


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

-Jim P.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: 

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

[Peter Gonzalez via dmarc-discuss]

On 2017 Jan 31, 05:59, Jim Popovitch wrote:
> On Sat, Jan 28, 2017 at 1:49 AM, Dave Warren wrote:
> > On Fri, Jan 27, 2017, at 04:23, Jim Popovitch wrote:
> >
> >> But what can you do about it?  What is the "value" of having that
> >> information, and what is the "cost" of capturing it?
> >
> > To me, the value of these reports is pre-deployment, by carefully
> > reviewing the reports you can identify any legitimate sources of mail
> > which are not properly signed and aligned.
> 
> I rolled out additional DMARC support for Mailman (outbound alignment)
> recently, and to be honest I'm not yet convinced that all receivers
> have a clue when verifying alignment... so it makes it much more
> difficult, for me, to trust the data.So... imho it's a waste of
> time/effort building an archive of suspect data until faith can be
> established in what is reported.

So what exactly did you do to "roll out additional DMARC support" in
your Mailman setup?

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.

> Here's a few examples for the same email:
> 
> Hotmail gets it right:
> http://domainmail.org/dmarc-reports/hotmail.com%21netcoolusers.org%211485698400%211485784800.xml
> 
> ItaliaOnline gets it right:
> http://domainmail.org/dmarc-reports/italiaonline.it%21netcoolusers.org%211485778386%211485778386.xml
> 
> VirginMedia gets it wrong:
> http://domainmail.org/dmarc-reports/virginmedia.co.uk%21netcoolusers.org%211485734404%211485820804.xml
> 
> CSP-Net gets it wrong:
> http://domainmail.org/dmarc-reports/bechu-vir0001.csp-net.ch%21netcoolusers.org%211485730804%211485817204.xml

I see in those samples you provide that DKIM is failing for some
messages. Could it be that some subscriber(s) to your mailing list has
set up some kind of subject-tagging and ulterior forwarding when he
receives your mailing list messages?

> So it's 50/50 for the same small sample of list traffic.   Do I care,
> sure!   If someone from Virgin Media or CSP-Net wants to explain the
> failures (or send me the RUFs that I already ask for) then I am all
> ears.   Until then, I remain a skeptic.  ;-)

Skeptic about what: about those receivers ability to properly check
DMARC, or about the usefulness to you of DMARC reporting?

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.

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/

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 Sat, Jan 28, 2017 at 1:49 AM, Dave Warren via dmarc-discuss
 wrote:
> On Fri, Jan 27, 2017, at 04:23, Jim Popovitch via dmarc-discuss wrote:
>> On Thu, Jan 26, 2017 at 11:13 PM, John Levine via dmarc-discuss
>>  wrote:
>> > I concur with Roland.  Looking at my failure reports, I see some from
>> > Hotmail and Linkedin and beyond that a few from Chinese and Russian
>> > ISPs generally reporting random spam that happened to randomly fake my
>> > domain.
>>
>> But what can you do about it?  What is the "value" of having that
>> information, and what is the "cost" of capturing it?
>
> To me, the value of these reports is pre-deployment, by carefully
> reviewing the reports you can identify any legitimate sources of mail
> which are not properly signed and aligned.
>
> As a company that currently has no employees beyond myself and only a
> few hundred clients, I was able to find a couple legitimate sources of
> mail coming from my own domain that had been previously overlooked.


I rolled out additional DMARC support for Mailman (outbound alignment)
recently, and to be honest I'm not yet convinced that all receivers
have a clue when verifying alignment... so it makes it much more
difficult, for me, to trust the data.So... imho it's a waste of
time/effort building an archive of suspect data until faith can be
established in what is reported.

Here's a few examples for the same email:

Hotmail gets it right:
http://domainmail.org/dmarc-reports/hotmail.com%21netcoolusers.org%211485698400%211485784800.xml

ItaliaOnline gets it right:
http://domainmail.org/dmarc-reports/italiaonline.it%21netcoolusers.org%211485778386%211485778386.xml

VirginMedia gets it wrong:
http://domainmail.org/dmarc-reports/virginmedia.co.uk%21netcoolusers.org%211485734404%211485820804.xml

CSP-Net gets it wrong:
http://domainmail.org/dmarc-reports/bechu-vir0001.csp-net.ch%21netcoolusers.org%211485730804%211485817204.xml


So it's 50/50 for the same small sample of list traffic.   Do I care,
sure!   If someone from Virgin Media or CSP-Net wants to explain the
failures (or send me the RUFs that I already ask for) then I am all
ears.   Until then, I remain a skeptic.  ;-)

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

[Dave Warren via dmarc-discuss]

On Fri, Jan 27, 2017, at 04:23, Jim Popovitch via dmarc-discuss wrote:
> On Thu, Jan 26, 2017 at 11:13 PM, John Levine via dmarc-discuss
>  wrote:
> > I concur with Roland.  Looking at my failure reports, I see some from
> > Hotmail and Linkedin and beyond that a few from Chinese and Russian
> > ISPs generally reporting random spam that happened to randomly fake my
> > domain.
> 
> But what can you do about it?  What is the "value" of having that
> information, and what is the "cost" of capturing it?

To me, the value of these reports is pre-deployment, by carefully
reviewing the reports you can identify any legitimate sources of mail
which are not properly signed and aligned.

As a company that currently has no employees beyond myself and only a
few hundred clients, I was able to find a couple legitimate sources of
mail coming from my own domain that had been previously overlooked.

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

[Steven M Jones via dmarc-discuss]

On 01/27/2017 04:23 AM, Jim Popovitch via dmarc-discuss wrote:
>
> I can appreciate that folks do that, and that's awesome.   For me and
> my systems that just seems like unnecessary overkill.

Ultimately that's a decision each domain owner/operator has to make for
themselves.

But I would hope that, like you, they've first gone through deployment
of DKIM and SPF and checked the DMARC reporting to see what's going on.
And even if they don't see many fraudulent messages and/or aren't overly
concerned about it, I would recommend setting something up to monitor
the reports and summarize or set an alert driven by changes/increases in
authentication failures. This way if something goes wrong in a legit
sending setup (ESP, etc), or if a bad actor does start abusing their
domain, they'll find out about it in short order.

--Steve.



___
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 Thu, Jan 26, 2017 at 10:33 PM, Roland Turner via dmarc-discuss
 wrote:
> Bear in mind that all reporting is at the good graces of receivers; the 
> options to fine-tune what is sent may, or may not, actually be implemented by 
> any given receiver.

Great point.  I do already see a fair bit of inconsistencies
("failures" from one or more receivers for the exact same data that
aligns at other receivers).


On Thu, Jan 26, 2017 at 11:13 PM, John Levine via dmarc-discuss
 wrote:
> I concur with Roland.  Looking at my failure reports, I see some from
> Hotmail and Linkedin and beyond that a few from Chinese and Russian
> ISPs generally reporting random spam that happened to randomly fake my
> domain.

But what can you do about it?  What is the "value" of having that
information, and what is the "cost" of capturing it?

> The aggregate reports tell you about both success and failures, so put
> them in a database and query for stats about the failures.  This is
> not, as they say, rocket science.

I can appreciate that folks do that, and that's awesome.   For me and
my systems that just seems like unnecessary overkill.  My interests
end when just 1 legitimate receiver verifies alignment, after that any
failures are 99.999% probably not my fault and most assuredly outside
of my control.

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

[John Levine via dmarc-discuss]

>I guess I'm now more inclined to remove the rua= stanza as I don't
>manage user accounts and am really only interested in the failures.

I concur with Roland.  Looking at my failure reports, I see some from
Hotmail and Linkedin and beyond that a few from Chinese and Russian
ISPs generally reporting random spam that happened to randomly fake my
domain.  The Hotmail reports are redacted so they are certainly better
than nothing but not that much better.  They will not give you anything
like a comprehensive view of where your DMARC failures are.

The aggregate reports tell you about both success and failures, so put
them in a database and query for stats about the failures.  This is
not, as they say, rocket science.

R's,
John
___
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?

[Roland Turner via dmarc-discuss]

Jim,


Bear in mind that all reporting is at the good graces of receivers; the options 
to fine-tune what is sent may, or may not, actually be implemented by any given 
receiver. (This isn't an interoperability or conformance comment so much as a 
real-world systems one. Postel's Law definitely applies.) Anything that you can 
reasonably do by yourself with the data that you are given is something that 
you should be willing to do, at least for some receivers some of the time. 
Trying to use the DMARC options as configuration tools to fine-tune what data 
you work with isn't likely to work very well, that's something that you should 
be doing with the tools that you use to process the data that you receive.


Disregarding (and even not requesting) aggregate reports is your prerogative of 
course, but note that even amongst receivers who will send aggregate reports to 
strangers (organisations with whom they don't not have formal NDAs), the vast 
majority will not send failure reports. Most of the useful information that 
DMARC will give you is to be found in the aggregate reports.


- Roland


From: dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of Jim 
Popovitch via dmarc-discuss <dmarc-discuss@dmarc.org>
Sent: Friday, 27 January 2017 07:43
To: John Levine
Cc: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

On Thu, Jan 26, 2017 at 5:50 PM, John Levine <jo...@taugh.com> wrote:
> In article 
> <cagfsgr0hs6eylx0key+j+5hpzuve1kfoufyn3j731d+xcr7...@mail.gmail.com> you 
> write:
>>Hello,
>>
>>I'm trying to limit RUA/RUFs to legitimate emails that need eyeballs.
>>
>>To that end, I'm scratching my head as to why I get RUAs that clearly align.
>
> That's how it works.  See section 7.2 of RFC 7489.  Aggregate reports
> tell you about all the mail a system got that has your domain on the
> From: line.
>
> Everyone I know automatically parses the aggregate reports and puts
> the info in a database so they can query it about whatever is of
> interest.
>
> Here's some scripts I give away that do the parse and put in a database part.
>
> http://www.taugh.com/rddmarc/
>
> R's,
> John

Thanks John,

I guess I'm now more inclined to remove the rua= stanza as I don't
manage user accounts and am really only interested in the failures.

-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)
___
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 Thu, Jan 26, 2017 at 5:50 PM, John Levine  wrote:
> In article 
>  you 
> write:
>>Hello,
>>
>>I'm trying to limit RUA/RUFs to legitimate emails that need eyeballs.
>>
>>To that end, I'm scratching my head as to why I get RUAs that clearly align.
>
> That's how it works.  See section 7.2 of RFC 7489.  Aggregate reports
> tell you about all the mail a system got that has your domain on the
> From: line.
>
> Everyone I know automatically parses the aggregate reports and puts
> the info in a database so they can query it about whatever is of
> interest.
>
> Here's some scripts I give away that do the parse and put in a database part.
>
> http://www.taugh.com/rddmarc/
>
> R's,
> John

Thanks John,

I guess I'm now more inclined to remove the rua= stanza as I don't
manage user accounts and am really only interested in the failures.

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

[John Levine via dmarc-discuss]

In article  
you write:
>Hello,
>
>I'm trying to limit RUA/RUFs to legitimate emails that need eyeballs.
>
>To that end, I'm scratching my head as to why I get RUAs that clearly align.

That's how it works.  See section 7.2 of RFC 7489.  Aggregate reports
tell you about all the mail a system got that has your domain on the
From: line.

Everyone I know automatically parses the aggregate reports and puts
the info in a database so they can query it about whatever is of
interest.

Here's some scripts I give away that do the parse and put in a database part.

http://www.taugh.com/rddmarc/

R's,
John
___
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)