On 5/8/15 5:19 PM, Murray S. Kucherawy wrote: > On Fri, May 8, 2015 at 10:29 AM, Anne Bennett <[email protected]> > wrote: >> Murray S. Kucherawy writes (with respect to ATPS if I got this right): > You did. >>>> There's still that pesky registration problem to address. >> Hector Santos writes: >> >> [...] >> >> Therefore, I don't think that SPF has a "registration problem". >> It has plenty of other problems, but not that one. ;-) > Agreed. >> But if I understand correctly, it's being suggested that for >> various proposals made here to work, either the sender's mail >> system or the final receiver's mail system would have to become >> aware of all of the "legitimate" (definition purposely left >> out!) mailing lists to which its users subscribe. >> >> To me, *that* is a registration problem. > Agreed again. And as Terry has said and I think we can infer about other > large operators, it's incorrect to assume (and plain wrong to assert) that > this is an easy problem for them to solve in a reliable way.
The current situation is NOT producing reliable results nor can it get better without additional information being made available from the DMARC domain requesting restrictive handling against non-transactional exchanges. DMARC must stop ignoring the role of Sender header fields, or make an effort to avoid disrupting legitimate, well formed, SMTP compliant, and socially beneficial exchanges. >> I believe that some people have claimed that this problem is >> easily overcome (or perhaps "worked around" would be a better >> expression) by examining mail headers and gathering statistics, >> and this may well be the case, but addressing the problem in >> this way will always depend on heuristics, just like any other >> anti-spam method. > Right; the claim is that this is a well understood problem and that the > cost of implementing it is low. For the DMARC domain, identifying legitimate third-parties can represent rather straight forward results determined by comparing recent output logs against DMARC feedback. Information that only the DMARC domain is able to authoritatively confirm. Arguing about cost misses the fact that expecting recipients to make this type of determination before imposing requested and possibly disruptive policy is simply not practical. We would love to have the opportunity to demonstrate the implementation of such a system at scale on behalf of a large provider. ATSP won't work, but can be altered to avoid requiring special DKIM signatures or indeterminate labels. Since this scheme would only come into play when handling otherwise restrictive handling, the impact would be small but highly beneficial by eliminating the disruption of valid, and socially desired messages. If there is a case to be made that restrictive handling is needed but is being misapplied against non-transactional messages, then there are two ways forward. 1) Recipients will decide the DMARC policy is too disruptive and not honor the requested handling by the disruptive domains. 2) Senders can recognize they must provide additional information to avoid disrupting socially valued services exchanging properly formed messages where the author remains apparent to recipients. > I don't agree. In addition to the above, no two operators will have > exactly the same idea of what fits here, or what components of their local > system they need to include. Punting on this as an "implementation issue" > leaves a pretty substantial hole in whatever gets rolled out. To me it's > like buying a car with a completely absent steering mechanism, and you have > to do the research to figure out which one fits and works for you, and > probably build it yourself too. Which is why we volunteered to help at implementing a solution that provides recipients DMARC domain derived information necessary to prevent unwarranted disruption of services. > At a minimum, we need to describe detailed requirements of this component. > Having something open source that works in general would also be helpful, > but at best we only have a rough sketch of what that would look like right > now. > > I cannot see how it would approach a reliable pass/fail result, A pass/fail result is possible only when DMARC domains offer necessary information that only they can assemble. The cost of sharing this information is extremely low for both the sender and the recipient. We did this as a free service for about 80% of the world's email at one time. Assembly of information may not be immediate but the collection of this information should be fairly stable. There may be some prompting required to ensure there are no gaps in coverage. >> which I've been told is what DMARC is all about: don't make the >> users have to decide anything! Handle it all before delivery! Removing risk exposure from recipients is fine. But don't toss out valued messages or obscure authors because avoiding disruption seems like too much effort. It is not. Shortcuts working without the necessary information will intimately prove even more problematic. I have an increasing number of legitimate messages ending up in my spam folder along with their look-alikes. Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
