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)
