Re: Dan Bernstein's issues about namedroppers list operation

[Vernon Schryver <vjs@calcite.rhyolite.com>]

> From: Paul Vixie <paul@vix.com>

>                 ...  spamassassin operates at the MUA level, and as such,
> the originating MTA receives a "final OK" and drops the connection before
> spamassassin begins its job. 

That is true of most but not all SpamAssassin installations.  There is
at least one and perhaps more than one sendmail milter interface to
SpamAssassin that should allow an MTA using SpamAssassin to reject mail
instead of giving a final SMTP OK.  

In addition, it should be straight forward to lash SpamAssassin to the
popular sendmail Perl milter machinery.

(I'm not endorse the SpamAssassin milter inferface(s).  I have the
impression that the SpamAssassin milter interface(s) are not directly
associated with those in charge of SpamAssassin itself. Some people
using the SpamAssassin milter(s) it (or they?) work fine, but others
have colorful comments.  I've seen problem reports supposedly about
the DCC milter that turned out to be due to a SpamAssassin milter.
What I've seen of the SpamAssassin milter sendmail.cf configuration
values also strike me as surprising except in a low volume mail system.)


>                               the MUA's only choices when dropping mail
> due to spamassassin's filtering are: issue a new message back to the sender
> to inform them of the bounce, or silently drop.  because most of the mail
> spamassassin will drop has an invalid sender address, choice #2 is common.
> ...

When SpamAssassin is used after the SMTP final ok, that is a good
argument for not to make that common choice and to send bounces, even
if they might go to innocent people or double-bounce into the local
postmaster mailbox.  From things said in the main IETF list, I suspect
such bounces would not have reached Dr. Bernstein.  However, that's
irrelevant to the general principle that bounces are necessary for
the special cases of IETF lists.


Vernon Schryver    vjs@rhyolite.com