Sorry, is this on topic?
--
Al Iverson | Chicago, IL | (312) 725-0130
www.aliverson.com | twitter.com/aliverson
On May 11, 2011, at 10:31 PM, Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
On May 11, 2011, at 7:53 PM, Laura Atkins wrote:
On May 11, 2011, at 3:15 PM, John C Klensin wrote:
I may be wrong, but I don't think either Keith or I are saying
"don't use blacklists in your systems". Keith, I think, comes
closer than I do. For all you know, I might even be using
blacklists as part of a scoring system (and I'm not telling).
What I think we are saying is:
(i) Don't force me to use blacklists or otherwise force
them on me or my mail.
No one forces you to use a blacklist or any filtering. Yes, it may be
difficult to find a commercial provider that doesn't run some sort of
blacklist, whether internally or externally maintained. However, you always
have the option to run your own mailserver and not check mail against any
blacklists. For instance, we don't want mail blocked due to blocklists so
we run our own server.
It's pretty impractical for most people to run their own servers. It takes a
large amount of expertise. Fortunately, there are still some commercial
providers that don't run a blacklist (or give you the option to turn it off
for your incoming mail). (But overall, the state of commercial mail service
providers seems to be pretty sad. I still haven't found one, for instance,
that will let me disable all use of unencrypted passwords.)
With all of that being said, I think this is out of scope for this
particular protocol discussion.
I don't think that whether a domain can use blacklists is open to question.
We've always said that an MTA can reject any message for any reason. I
personally think that rejecting messages based on source IP address
(regardless of the reason) makes for a lousy heuristic, one which will get
worse over time (especially in IPv4 with the increasing use of multi-layered
NATs). The spammers have long since figured out how to get around IP-based
filters. But I won't pretend that we can talk people out of using them.
All I'm asking for in the context of the current discussion is for enhanced
status codes to distinguish "rejected because of a blacklist or reputation
service" codes, from codes that indicate a failure in the signal path.
Keith