RE: uncooperative DNSBLs, IETF misinformation (was: several messages)

> >> - 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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf