> 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