RE: sender rewriting scheme

> > Alan answered it best:  Nope, otherwise we're back to Square One.
>
>   Was I that articulate?  Hmm...

Sounded like it.  :-)

>   Since the scope of the problem we're addressing is EHLO/HELO, and
> MAIL FROM, then .forward shouldn't be an issue:
>
>   a) EHLO/HELO contains a valid FQDN for the MTA
>   b) MAIL FROM contains the username at that domain who consented
>      to forwarding the message.

b) suggests that the sender envelope changed somewhere in the .forward
process.  I don't think this happens with MTAs that support .forward files.
If it did, then .forward wouldn't be an issue.

>   e.g. an MTA which sends:
>
> EHLO [127.0.0.1]
>
>   is conformant to RFC 2821.  Yet it's behaviour is obviously
> nonsense.

Let's take a look at that, actually.  It's been mentioned elsewhere already,
so bear with me for a little bit.

If some MTA did that and it wasn't actually trying to connect from localhost
to localhost, DMP and SPF don't care since they look at MAIL FROM first. [1]
They'd only look at EHLO for null envelopes.  And then it'd bounce it for
being nonsense (except if [1]).

I have to agree that we're encouraging MTA vendors and admins to rise a bit
above RFC 2821, but that's the whole point of this exercise, no?

[1] DMP/SPF wouldn't even be attempted if localhost was an authorized
sender.

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email protected]>
What's a PGP Key?  See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>