Hector Santos writes: > This is a long time issue and I have been there since day one,
I haven't participated in IETF discussions before. But my personal site was abused as an open relay in 1995 because Smail 100.something advertised a no-relay config option but didn't implement it (so I had to, while apologizing to a large number of pissed-off postmasters), and I have a Zumabot T-Shirt. > Again, as a SOFTWARE DEVELOPER, you have to cater to all market > needs. I disagree. Software developers cater to the needs they want to, including both pure good will and for-profit reasons for wanting to. In this venue, many of us *want* to see protocols that work for everybody all the time. Me too. However, as a MLM developer, I have to say that in practice, the 9+ years of IETF engineering work has dismally failed to achieve universal inclusion. Both SPF and DKIM marginalize mailing lists because they relegate them to world of unauthenticatable traffic. In practice, too, software developers regularly fail to satisfy some of the market's needs. Does that mean y'all owe us a pony? It does not. In today's Internet, much as I hate to admit it, Mailman-style lists are a bit marginal. On the other hand, the Kucherawy-Crocker dkim-delegate draft looks like a way forward for mailing lists, and I don't understand why you and Vlatko feel the need to deprecate it in such strong terms. > As it was predicted, we have the same dilemma with DKIM now. It is > yet another philosophical, wasteful discussion on the merits having > strong signature policies. I don't have a problem with strong signatures. I do have a problem with the way existing protocols marginalize mailing lists. I do have a problem with the way DMARC "p=reject" can be abused and interfere with mailing list traffic among other classes of email. I think there are valid reasons for worrying about the potential negative effects of strong policies especially if they try to mandate rejecting mail before the DATA transaction, and I disagree that: > This concept has long been resolved by the market. It is a highly > desirable feature and idea to be able to take control of your > domain again. in the sense that as desirable as it may be, for the vast majority of mailboxes, it probably cannot be implemented without losing a lot of mail and perhaps having other unfortunate effects (eg, the thousands of mailing list subscriptions that were disabled or even terminated due to Yahoo! bounces). And I doubt the average Yahoo! user would be pleased to understand the full meaning of "control" as implied by that domain's "p=reject" policy. So AFAICS these "strong policies" remain as controversial as ever, and progress is going to have to be made in small steps. DMARC, IMHO, was a remarkably big step by this criterion (but then, it has built on a lot of experience of failed or marginal proposals). > As it was done with SPF, over time, the private domains, the higher > value domains, began to use SPF -ALL policies, even the IETF is > telling the world only their machines send out @ietf.org related > mail: > > "v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56 > ip4:64.170.98.0/24 ip6:2001:1890:126c::/56 > ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64 > ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64 > ip4:72.167.123.204 -all" Sure. I can't imagine why (except for fear of Murphy) anybody would publish anything else. (Well, actually I can, but I don't think that discussion is particularly useful.) What I don't agree with is using *only* the information about source IP and SPF policy as a spam filter in a store and forward architecture with mediators. And I think this idea has been completely rejected by the market (as opposed to blacklisting known spam source IPs, and using SPF policy and source IP as one datum among several for assessing abusiveness of a message). Are there really sites out there that reject on the basis of SPF -ALL without waiting for DATA? I for one could not use such a host. > This could tell the OPTIMIZED RECEIVER thats ok to reject before DATA > is reached, even though the SPF -ALL already tells you its ok. Well, no, in the real world SPF -ALL *doesn't* tell you that. It tells you that you can trust those hosts for traffic claiming to be from the corresponding domain. But you risk throwing away legitimate messages if you reject just on the basis of that SPF record. Even in the bank case: I get a notice from my bank at home, but that account is automatically resent (.forward) to my cellphone. If my cellphone provider bounces it because of SPF, I would be quite annoyed. (DMARC is a big improvement here, because it won't bounce due to DKIM identity alignment.) The fact is, with the exception of blacklisting truly evil hosts, making a decision to reject based on the client's IP address and the domain(s) in HELO and MAIL FROM is just a recipe for throwing away a lot of legitimate mail and users in most domains will not stand for it. > Only with IETF endorsement will it begin to get wider adoption > within the market. DMARC proves that wrong. What DMARC shows, AFAICS, is that what is needed to get adoption in the market is a protocol that does what it is designed to do *and* satisfies real needs. Not to mention that in IETF tradition this whole sequence of anti-mail-abuse standards is somewhat unseemly, as quite clearly many were hopeful stabs in the dark based on a lot of theory and a little bit of urgency, rather than codification of successful practice.[1] > Have you tried ADSP/ATPS or DMARC with ATPS updated for DMARC > instead? Uh, no. I'm interested in this discussion because I administer mailing lists and develop MLM software, not MTAs. So implementing those protocols has not been a possible experiment for me. I'm working on getting control of the MTA for some of the public mailing lists I administer, at which point I may experiment with it. It's not clear that the experiment would be very meaningful, though, as those lists have very few Yahoo!/AOL subscribers, and none who have posted from those domains in years. In any case, ADSP is now historic, and it would appear to be superseded by DMARC; I'm not sure what the point of trying ADSP is. Footnotes: [1] Granted, it's not just mail security standards that have moved to adoption on the basis of theory, the whole IETF process is doing it. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
