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. > 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. 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. 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, > 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! > > What am I missing? > Not a thing. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
