[Top] [All Lists]

Re: slight update to draft-macdonald-antispam-registry

2011-05-11 22:47:48

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.