Paul R. Ganci wrote:
This is somewhat a philosophical question, but I will ask it anyways.
Recent discussions have occurred on this list regarding what
Spamassassin should do with Spam. The recent consensus seems to be that
it is only Spamassassin's job to tag Spam and that some other program
should decide what to do about it. I can accept this argument especially
in regard to the old "spam_action" config option especially when set to
"delete".
However, I have a user who raises a good point. He has a blacklist in
his user_prefs. Spamassassin processes his Email message and indeed
finds this blacklisted message as USER_IN_BLACKLIST shows up in the
header. In addition lots of other processing occurs before the final
score of 99 is tallied. His question is simply this: "Why does this
message show up in his box at all?" His point being the message was
blacklisted. Why is it not a good idea for Spamassassin to immediately
send to /dev/null a message flagged in somebody's blacklist ASAP ...
i.e. no further processing? Is the only way to handle this via a
procmail recipe? Similar what about a whitelist ... shouldn't it be sent
on as Ham ASAP ... i.e. a minimal of processing? How do others handle
these cases?
Paul,
here's my take on it. keep in mind i'm in no way affiliated with the
developers, it's just my opinion as a mail system administrator and
SpamAssassin user.
for one thing, SA has been designed for specific reasons *not* to
process the mail, but only to add headers as necessary. One of these
reasons is that SA can remain extremely versatile in this configuration.
for instance, I use SpamAssassin via a call from MIMEDefang which runs
as a Sendmail Milter. Others may call spamassassin/spamc from procmail,
others may integrate with qmail-scanner or amavis-new (neither of which
am I familiar with, but they get quite a bit of mention on this and
other lists)
For SpamAssassin to be able to do SMTP level rejections, it would have
to *always* be integrated into the MTA. Granted there are tools to
allow the integration of SA into the MTA, but they are designed and
supported by third parties (and in my opinion, rightfully so).
Philosophically, it makes more sense for SpamAssassin to focus on
identifying SPAM, and let another application (MTA, procmail, etc) focus
on what it was primarily designed for: processing
(delivery,rejection,etc) of said email. It's certainly no more of a
hassle to add a procmail rule to dump a blacklist hit to /dev/null than
it is to add a procmail rule for other delivery options.
There may be cases where it would be very inappropriate for *any* mail,
blacklisted or not, to be dumped to /dev/null. having SA have to
account for all possible handlings of blacklisted mail would add more
bloat and logic requirements to the code which, in my opinion, aren't
necessary.
When you're dealing with mail delivery, you have to account for local
delivery inconsistencies, whether the mail will be delivered to a remote
machine anyways, etc. again, these types of situations make it more
appropriate for applications written specifically to handle them than to
try to add them to SA and pull the focus away from identifying SPAM to
delivering mail.
just my $.02 worth.
Alan
