Re: sender rewriting scheme

On Tue, Oct 07, 2003 at 07:07:12PM -0500, Gordon Fecyk - Home wrote:
> >   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]).

About the only time "HELO [127.0.0.1]" is valid if I'm connecting from
<drumroll> localhost.  e.g. in sendmail 8.12, and I invoke sendmail from 
the command line... it now puts the qf/df files in /var/spool/clientmqueue
(which is NOT owned by root, but a special user) and then initiates an
SMTP sesstion to localhost (to talk to the daemon that *is* root, but 
no longer needs to be invoked setuid for all incarnations)

For all I know it says "EHLO [127.0.0.1]"  but it could just as easily say
"EHLO localhost".   Either one is valid.  And both are unverifible for
any DRIP/RMX/SPF.  

But the current DRIP milter, in its finite wisdom, sez "you are connecting
from 127.0.0.1, that's *me*...  If I can't trust me... what *can* I trust?"

Just as it would for any other IP addrs that we "trust" (say a local NAT
addr that might contain some hosts that don't 100% behave in RFC2821 
compliance, but you want to be able to send/receive mail from)

> 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?

Amen.   Let's raise the bar... a little.   Just enough to minimize the
pain.  And maximize the gain.

-- 
 /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/    <[email protected]>
 /  \__/ | It is dangerous to be right, when the government is wrong.
 \__/    |                                              -- Voltaire