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