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] A bit quiet?

[Roland Turner via dmarc-discuss]

John Payne wrote:


> Spoke too soon. I'm getting reports of IETF list mail from @akamai.com ending 
> up in Gmail spam folders :(
>
>> On Jan 31, 2017, at 9:07 AM, Payne, John via dmarc-discuss 
>>  wrote:
>>
>> And it did the trick.  Down to a manageable number of failures now, thanks 
>> for the hint Brandon :)

Presumably this just indicates that the rewrite rule that Brandon described for 
Google Groups is not in use by IETF's mailing lists?

Tradeoffs in every direction...

- 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] A bit quiet?

[Payne, John via dmarc-discuss]

Spoke too soon. I'm getting reports of IETF list mail from @akamai.com ending 
up in Gmail spam folders :(

> On Jan 31, 2017, at 9:07 AM, Payne, John via dmarc-discuss 
>  wrote:
> 
> And it did the trick.  Down to a manageable number of failures now, thanks 
> for the hint 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] 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)