-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Thomas wrote:
Walter Dnes wrote:
Maybe the only permanent answer is to...
- *not* deny that there may be *SOME* harm from DNSBLs
- but show that there is *MORE* harm in *NOT* using them
It doesn't seem to me that boosterism is really the right answer
though. DNSBL's are what they are. What would be nice to know as
an outsider is _what_ they are, how they roughly work, what their
upside is, and what their downside is. That way you can make the
risk/reward tradeoff which is invariably context sensitive.
I think as a nutshell, from the IETF perspective, Church's draft would
have to:
a) become a DNSBLs _may_ be harmful if you don't...
b) _know_ what the filters you're using actually do (at least
in terms of results).
As such, it could be a kernel for a more general "filtering BCP" paper.
But I don't think Church is willing to write one of those ;-)
[I've written a sketch for one, but nothing beyond that. There was a
mailing list created by Crocker (I think) to carry that onwards to
something useful, but that mailing list was DOA.]
- a DNSBL will send a 5XX reject to a legitimate sender's MTA, which
will notify the sender of the reject.
It doesn't have to. But it can (and does in perhaps most implementations).
- a content-filter will bury the email in a "spam folder" with
thousands of real spam, where it'll probably never be found. The
sender will believe that the intended recipient has received the
message and ignored it, while the intended recipient will believe
that the sender hasn't sent the message.
It doesn't have to. But it can (and does in many implementations).
That depends a whole lot on the receiving end's policy, doesn't it?
Spamassassin for example can use DNSBL's, the result of which is
effectively silent discard. And it would be a fairly trivial exercise
to make Spamassassin cause a 5xx to be generated for > 5.0 SA scores.
You have to be careful in your generalizations. Virtually _no_
filtering (aside from things like grey-listing) forces you to adopt one
form of disposition or other.
In our installation: DNSBLs reject inline _AND_ quarantine[+] (which
means it still takes the session up to the end of DATA, and then 550's
that).
Similarly, our content filters, including SpamAssassin, ALSO reject
inline and quarantine (550's after DATA). There is no "post-accept"
filtering of any consequence in our environment (except for the
infrastructure A-V to catch the viruses the front end filters miss, and
a few users using their own client-end filters).
[+] Quarantine is conceptually equivalent to spam folders, but
implemented differently.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRDFI+Z3FmCyJjHfhAQKz3wP+J6vnFEdg2uwdAXG6Fo7UBMLViXQphZQg
IAqCBcKT34nzFZKKNWqtXvj5g9gyCfyH5corIqobymZ6gXuOyMe3KhYFmJzUd40K
+0V1kb120Z4YSPV/4vkGoFSyJFTiOD7OrQ50/MdCumSjL5sgFoyOEXjvfrQFF0ct
1ufHI3Hrevo=
=d8Ry
-----END PGP SIGNATURE-----
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg