ietf-mxcomp
[Top] [All Lists]

Re: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd)

2004-09-16 21:21:02


----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Thursday, September 16, 2004 8:06 PM
Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd)


Out of curiosity, I use an MSA enforcing a valid MAIL FROM.
This MSA uses SMTP-after-POP (and before you laugh, that's
not much worse than insecure PLAIN or LOGIN).  What are the
corresponding Authentication-Results ?  Here's my guess:

I don't understand this reason for this.

The problem is :Final Destination mail from Anonymous Senders."

Local ISP users who are "malicious" and/or "abusive" is an administrative
problem.  You can probably add technical logic such as limits, but overall
the authenticated ISP user is not the problem the world is facing with
abusive final destination anonymous senders.

Remember what the standard mode of SMTP is:

  1) Authenticated or IP allowed clients can send local and remote mail.
  2) No authentication is required for final destination mail (local).

In other words, anonymous senders can not send remote mail.

So the anti-spam technological pressure point is at #2.  Not #1.

This is a key factor most people seem to forget.  RFC 2821 has provided us a
DOOR to help solve the problem and also run in a more optimized mode with a
method that none of the MARID proposals use or consider.  See RFC 2821
section "3.3 Mail Transactions"

   Despite the apparent scope of this requirement, there are circumstances
in
   which the acceptability of the reverse-path may not be determined until
one
   or more forward-paths (in RCPT commands) can be examined.

What it says is this:  You have 3 states points in SMTP:

    EHLO/HELO
    MAIL FROM
    RCPT TO:

Everyone is worry about the first two states before RCPT TO is known.   They
are proposing changes to SMTP receivers where overhead is added to check the
first two states.  A blind check with total disregard to establishing the
critical information of final destination or remote mail.

The section 3.3 suggestion is to simply delay the "overhead"
authentication/validation logic for EHLO/HELO and MAIL FROM until RCPT TO is
known. In practice, it works wonderfully.  You can save a tremendous amount
of your ANTI-SPAM overhead using this key method.

Remember again, if RCPT TO is not a local user, then the transaction becomes
a RELAY, thus the client IP and/or MAIL FROM must be authenticated using
standard SMTP technology already in place.

However, if RCPT TO is a local user, then SMTP says that you must accept the
mail regardless of the sender. That is the golden rule and also the reason
for the SPAM problem.

So in short,  this is a Final Destination Anonymous Sender issue.  I don't
see a need for MARID or anti-spoof overhead if the client is authenticated.

Thanks

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office



<Prev in Thread] Current Thread [Next in Thread>