On Tue, Jan 31, 2017 at 11:14 PM, Roland Turner via dmarc-discuss <dmarc-discuss@dmarc.org> 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)
