Re: sender rewriting scheme

"Alan DeKok" <[email protected]> Wed, 08 Oct 2003 13:03:13 -0400
Newsgroups gmane.ietf.asrg.rmx
Message-ID <[email protected]>
"Gordon Fecyk - Home" <[email protected]> wrote:
> >   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.

  The issue is that I *know* I have no .forward files on machines in
China.  e.g. I receive a message with a EHLO for a valid domain, and
that domain says "yes, that IP is allowed to send email as me."  If
the MAIL FROM then says "[email protected]", I *know* it's spam.

  If I had a .forward file in that domain in China, then I would have
to accept the message, as probably being forwarded on my behalf.


  This means that ANY use of MAIL FROM means that MTA's will need to
have white-lists which are applied *before* checking the MAIL FROM,
but after checking the EHLO.  e.g. "bob has a .forward file in
china.com, so don't check MAIL FROM for messages to bob with EHLO
china.com"

  Yuck.

  The use of DNS-based filtering on EHLO/HELO has many fewer problems
and issues than that for MAIL FROM.

> > EHLO [127.0.0.1]
> >
> >   is conformant to RFC 2821.  Yet it's behaviour is obviously
> > nonsense.
...
> 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]

  My contention is that the entire envelope has to be checked as a
whole, so we can't have the concept of order in the checks we do.  We
probably need to come up with a 3-tuple describing EHLO, MAIL FROM,
RCPT TO, and go through the variations of 2 remote domains, 1 local
domain, and various IP's.

  e.g.  for (EHLO, MAIL FROM, RCPT TO), 

  (ip, ip, local) = probably a spammer

  (domain1, domain2, domain3) = relay attempt

  (domain1, domain2, local) = message is .forward'd

  (domain1, domain1, local) = message from user at domain1


  ... etc.  Such a list would help us describe which solution applies
to what situation.

  I'll try to type up something today.

  Alan DeKok.