Re: [Asrg] Some data on the validity of MAIL FROM addresses

> From: Kee Hinckley <nazgul@somewhere.com>

> We've been through this before.

Really?  I must have been asleep, because I don't remember.

> Spam is in the eye of the beholder.
> Therefore some spam filtering rules need to be per-user.
> Milter's (and many other systems) don't give you enough information 
> to determine who the final recipient is--not to mention that their 
> may be more than one, with different standards.
> Therefore it is not always possible to reject things at the SMTP level.
> But yes, everyone agrees that you should if you can.
> Therefore--encourage it, but don't depend on it.
> Can we move on?

You can move whenever and wherever you wish.  I prefer to move with
an accurate map instead of capricious prejudice.

In fact the sendmail milter interface generally gives sufficient
information for per-user rules during the SMTP transaction.  That's
how the DCC sendmail-milter interface, dccm, is able to support per-user
white/blacklists.  The DCC source even includes a CGI interface for
user point-and-click fiddling with per-user white/blacklists based on
per-user directories of suspect messages.  That no DCC users like it
even enough to say it needs improvement suggests I'm an exceptionally
bad GUI designer.

I don't know but assume that the SpamAssassin milter interfaces (I
think there are two) use the same information for per-user rules and
scoring; it certainly could.  I don't know but suspect the milter
mechanism does not handle .forward files, but I don't think that's a
significant problem.  The milter mechanism handles alias files and at
least some other things that cause sendmail to forward the message
elsewhere in the sense of telling the milter filter program as much.

The biggest practical problems I can think of for per-user filters
using the milter mechanism are that sendmail wants to do things
with the UID "daemon" or equivalent and that the SMTP protocol
doesn't let the SMTP server answer the DATA command with "250-ok
for Rcpt #1, 550-spam for Rcpt #2, and 450-try-later for Rcpt #3."

Moreover, whether some or all current MTAs do or don't give you enough
information to determine the final recipient is an implementation
choice that is irrelevant here.  The BCP and long standing recommendation
and practice that an MTA should figure out the validity of each Rcpt_To
value as it is presented implies that an MTA designer ought to have
the final recipient figured out before saying "250 OK" or "550 Bad".

Vernon Schryver    vjs@rhyolite.com
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg