ietf-mxcomp
[Top] [All Lists]

Re: plan for april 5th xmpp conference...

2004-03-31 02:01:37


----- Original Message ----- 
From: "Matthew Elvey" <matthew(_at_)elvey(_dot_)com>
To: "Aredridel" <aredridel(_at_)nbtsc(_dot_)org>; "MXCOMP" 
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Tuesday, March 30, 2004 11:53 PM
Subject: Re: plan for april 5th xmpp conference...


I think that's a little prohibitive, simply because of the complexity it
will add to implementations. At the moment, MTAs don't look at the
headers much if at all -- just the envelope.

Nonsense.  I believe most Internet MTAs do content-based spam-filtering
already.

But as a system administration policy, not as a SMTP protocol compliancy
policy.

Two separate things.

I think we want a system that is 100% independent of mail interpretation and
the intent, strictly SMTP compliancy.

The "relax" provisions we have now is what encouraging post SMTP validation
and the email spoof/virus have now exploited this mode of operation to the
fullest extent.

I don't care who is sending mail, good intention or not,  it isn't done with
as a SMTP compliant system, it isn't getting in, period.   It is extremely
rare to have false negatives (rejections) and the only people that complain
are the few it can happen to and it is quickly adjusted/fixed, but certainly
the spammers (over 70-80% of which are spoofers) are not complaining.

2821 validation is what we want.  Leave 2822 validation to system
administrators.

If we want to make a provision somewhere that there is a strong association
(or equal) with 2821 MAIL FROM and 2822 Sender:,  great!  fine!  Even
better, but that still should not enforce or add pressure for a new design
requirement for systems accept mail first in order to implement this new
logic.    Note, I am speaking in general.  We can probably do this for our
system, but I believe it should be a fixed requirement for a transport
system.  Besides, what is Sender: isn't there? We accepting mail for
nothing.  So what if they must be equal.  MAIL FROM stills need to be
validated on its own face value.

Or are you saying that it can help reduce the need to validate a MAIL FROM
is the SENDER <> MAIL FROM?

   if Sender != MAIL FROM then
         reject
   else
        Validate Mail From
   end if

Something like that?  That make sense, but leave it as system administrator
rule.  Not a SMTP protocol rule.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com