On Fri, Feb 3, 2017 at 1:50 AM, Roland Turner via dmarc-discuss <[email protected]> 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 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. I prefer to take the high road and make an effort to remove the warts rather than than acquiesce into their acceptance. > 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. See my above comment. -Jim P. _______________________________________________ dmarc-discuss mailing list [email protected] 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)
