On Jan 4, 2008 11:27 AM, Joe Greco <jgreco@ns.sol.net> wrote:
"Be liberal in what you accept, and
That particular philosophy has done great wonders for e-mail and the spam problem
Joe,
I've heard similarly unsubstantiated versions of this claim over and over.
All right, here you go, then: You already cover pre-banner pipelining. Failure to reject HELO that is missing. This situation is generated often by direct-to-MX mail submission programs for webforms, etc. While most of these direct-to-the-local-MX, and are therefore of less concern from a global interoperability point of view, some of them are sufficiently smart to do the MX lookup for the destination, and connect to somewhere remote. Failure to reject HELO that is simply wrong ("exchange.local" or whatever it is). The guidelines for sending should require a host to determine its legitimate PTR, or, alternatively, at least a valid hostname (for those behind NAT). A mail server should refuse to run if it cannot even determine its own name can be resolved. Failure to include an anti-blowback mechanism within SMTP. Specifically, there's a wide-open default-valid sender of "<>", and some sites actually disallow this sender because spammers use it. This is horrifying, because it breaks mail failure notification, which further breaks the reliability of e-mail. One solution would have been for SMTP to include a consistent way for mail servers to be able to identify legitimate returns. The implementation of this that I've seen simply records Message-ID's on the way out, and should a NDN return which contains such a Message-ID, it is passed on. This requires database support at the sending site, which may be too high a bar. Had a method to sign a message, and guarantee that the signature be returned by any reporting MTA, been included in SMTP, it would have gone a long way to keep this working. There are still problems with it, of course, and the logical evolution moves on towards some of the solutions we've seen, but the failure to provide it out of the box and make sure every site supports it has created a mess. Failure to require a legitmate e-mail address in From:. Failure to require something like SPF from day 1, which might have made SPF useful. Do you want me to substantiate any more? I'm sure I can keep going.
The fact is I've done quite a bit of development on anti-spam systems and the only protocol violation that has been consistently valuable for rejecting spam is the fire-and-forget violation.
If you choose to count only "consistently valuable," then, you eliminate a bunch of things that are in fact pretty good spamsigns, but which are not 100% reliable.
That's the one where they pipeline the entire send-side of the conversation in the first data packet without waiting for the banner or checking each response as it comes back.
Except there's a bunch of old web form submission scripts that do that, so that's not 100% either.
Its a terribly tempting optimization to the spam-sending process and not enough servers detect or reject it.
Just as pretty much any other anti-spam optimization is terribly tempting.
Anti-spam activity at the protocol level is looking for behavioral signatures unique to spammer software. Protocol-correct signatures are just as valuable as protocol-incorrect ones but its all a game of whac-a-mole. Once a signature is identified and promulgated, the software exhibiting it either versions or falls out of use. A few months later the folks still nailed are the false positives.
The ideal thing is to key on things which legitimate mail servers should not be doing. Some of these are things which are difficult for a spammer to work around. Consider a policy that says: "Do not accept e-mail from an IP address on a dial-up users blocklist."
I'll second that sentiment. Seth's customer is unambiguously wrong. Unfortunately, that doesn't make Seth right. Missing brackets has been a common SMTP error since the inception of the protocol, second only to incorrect end-of-line (LF instead of CRLF). If you want your implementation to be robust, you have to silently allow those common mistakes.
Silently allowing those common mistakes is what allows users of those mail server products to think that their mail server is okee-dokee. If they were to find themselves unable to mail most places, the error (and whose error it was) would be more clear to them. Whether any particular error is worthy of being silently allowed is not a discussion for this forum, but I would say that a majority of them could have and should have been disallowed from Day 1. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.