[Top] [All Lists]

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

2011-05-11 23:55:56

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

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.

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

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?

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


Hector Santos