SMTP addresses in <>

> > "Be liberal in what you accept, and
> That particular philosophy has done great wonders for e-mail and the spam
> problem


I've heard similarly unsubstantiated versions of this claim over and

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

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.

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

Just as pretty much any other anti-spam optimization is terribly

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

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