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
--
Sincerely
Hector Santos
http://www.santronics.com