> >> - DNSBLs are a temporary fad, they'll never last. > >> (we've been serving DNSBLs for 10 years) > > > > Longevity is no guarantee of future survival. > > A good argument against publishing a standard for any > technology at all. Not at all. But it seems to me that the IETF does try to design standard protocols that have a chance at longevity. > This theory can be tested and you guys at BT could be the pioneers: I have no idea what theory you are talking about testing. I was making a comment about what might have been. Obviously, time has passed and there is no longer any opportunity to test what might have been. In addition, my comment about the past had nothing whatsoever to do with any particular company or ISP. It was a comment about the feedback loop between DNSBLs and spam volumes. The more effective DNSBLs are, the more volume of spam is sent by the spammers who rely on people buying the products that they advertise. > > Hmmm. No data provided, so no maths is possible. > > I thought perhaps you might be with BT's mail engineering > team. Not even close. > customers. (If you're not with BT's mail engineering team I apologize) If you promise to not make unwarranted assumptions about IETF participants in future, then I accept your apology. You might want to read this <http://www.ietf.org/tao.html> > How many times have you sent an email and your recipient says > days later "I didn't get it" and you say "well you must have > since it didn't bounce back" and both of you waste time. Yes it's true, the Internet email architecture has a number of holes that can break deliverability. DNSBLs are only a part of the problem. > DNSBL technology maintains the fundemental rule of email > deliverability: If an email can not be delivered *inform the Sender*. First of all, the draft only says that there SHOULD be a TXT record with a reason and that it "is often used" as the text of an SMTP error response. The draft doesn't actually say anything at all about informing the sender, only about the sender's mail server. But then, the draft is defining the DNSBL protocol, not the entire architecture. At this point I'm beginning to wonder whether the IETF should even publish this as an informational RFC. After all, the information is already public and the authors can publish the substance of this protocol elsewhere if they choose. If there was a working group to publish a set of RFCs that cover the whole area of DNSBLs and filtering then this would make a fine document for that WG to start with. But on its own it leaves too many loose ends. --Michael Dillon _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf