ietf-smtp
[Top] [All Lists]

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

2011-05-12 06:28:08

On May 12, 2011, at 12:38 AM, Hector Santos wrote:

Keith Moore wrote:

(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.)

Pretty Sad because you can't do this? hmmmm

that's just one example that I find particularly irritating.    part of the 
issue is that too many MUAs will try using plaintext passwords (without asking) 
if password-over-SSL fails for whatever reason, thus exposing the password in 
cleartext.  this is a disaster on a typical wireless network.

Most of the time its for good reasons - product liability, PCI requirements, 
etc.  But even then, that hasn't prevented people in breaking security needs 
by adding wrappers into their new user accounts/change passwords to save the 
plain text somewhere before a server secured the password storage.

There is no longer any good reason for using plaintext passwords, particularly 
not for customers who have their own domains and can select their own user 
agents.

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.  

True, but it would be pretty sad if receivers reject mail without good 
reason. RBL exist because it provides a payoff to filter the abusive side of 
mail.  If it didn't, people won't use it.

I'm not going to argue about why RBL exists.

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 only issue I've see with NATs is with EHLO [ip-literal] enforcement. For 
example, (LAN/WAN/Wireless) private IP network client use EHLO 
[local-mach-ip] and the peer connection IP is that of the public IP NAT 
machine - an SMTP violation.

some ISPs are already NATting several customers behind a single address or 
address block, so that the source address of a TCP connection is no longer 
uniquely associated with only one customer at a time.  this will only get worse 
over time because IPv4 addresses have been exhausted.  one implication is that 
any attempt to associate a reputation with an IP address, even temporarily, 
becomes increasingly dubious.

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.

That sounds more like an SPF issue, not RBL. no?

it applies to both, though the codes for the two should be distinct (as is 
proposed).

X.8.3 seems to cover RBL - "IP listed on RBL RBL-NAME"
X.8.12 seems to fit SPF - IDENTITY is an un-delegated IP


the issue is that the 2nd facet value of '8' is being used both for conditions 
determined locally and conditions determined by a 3rd party.

Keith