On Wed, 2004-02-25 at 12:55, Justin Mason wrote:
Another advantage is that, if I receive mail via 1 or more relays (think:
ISP's MX, workplace MX, .forward, cpan.org forwarder, etc.), I will
have no access to the original HELO/EHLO otherwise.
This data is very useful for filtering.
We've discussed why EHLO arguments are worthless from a protocol
standpoint and why they are useful from the ad-hoc anti-spam ruleset
standpoint.
But, if "everyone" adopts SPF and eventually we start falling back on
"-all" records, then you will have authenticated the host as an
allowable sender based on the envelope sender's domain, so the EHLO
doesn't really matter.
There is the edge condition that null envelope senders can't be
validated and some argue that the EHLO argument is useful then. I think
the null envelope sender should be complete depicated, but that should
be handled by another initiative.
This is yet another reason horrible cost-shifting CBV systems will
eventually die. My mail server could accept a(_at_)b(_dot_)com as a valid
recipient if you put user1(_at_)example(_dot_)com, but return a 550 if you use
<>
as your sender. It is a _valid_ email address that does not accept
messages from the null envelope sender. A CBV system will incorrectly
fail that address as "invalid." Yet another in a long list of reasons
that the null envelope sender should be deprecated.
So, as far as I'm concerned everyone can check things up the ying-yang
and back for null envelope senders because responsible MX owners should
be bouncing message DURING the smtp session and responsible remailers
should be using one for of returnpath rewriting or another.
--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on earth