[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sa-exim: What user does spamassassin run as?

On Wed, Oct 15, 2003 at 07:24:37PM -0700, Paul Johnson wrote:
| On Wed, Oct 15, 2003 at 12:49:55PM -0400, Derrick 'dman' Hudson wrote:
| > The other method I've documented for integrating sa with exim performs
| > the processing after the message is accepted and on the queue and
| > scans the message once per recipient.
| Since you know way more about sa than I do, what are the odds of
| seeing a dman patch submitted to sa-exim?

Patch to do what?

I don't care what software you use, SMTP does not allow applying
different content-based restrictions for difference recipients.  The
SMTP conversation goes like this (englishified for fun and possibly
for greater comprehension) :
    >>> Hello, I'm the <foo> mail system.
    <<< Ok, nice to meet you.
    >>> This message is from <dman@dman13.dyndns.org>
    <<< Ok, this sender is accepted.
    >>> This message is for <baloo@ursine.ca>
    <<< Ok, this recipient is accepted.
            *** Here's where the problem lies ***
    >>> This message is also for <another_user@ursine.ca>
    <<< Ok, this recipient is accepted.
    >>> The message data (headers and body) is as follows:
    <<< Ok, ready for data
    >>> [... the message data ...]
            * Here is where sa-exim makes its decision.  It either
              accepts the mail for all recipients or no recipients. *
    <<< [Ok, data accepted]  or  [No, I don't take that crap]
    >>> Goodbye

The problem is that you can't reject the DATA for certian RCPTs and
not for others.  sa-exim only scans the message once, and must do so
with a single rule set.

The other spamassassin integration (the one I documented extensively,
before sa-exim was written) doesn't operate during the SMTP
conversation.  Instead the mail is first accepted by your server and
placed on your queue.  Then exim passes it through the scanner as it
delivers the message, which means that the scanning is performed
separately for each recipient.  Naturally that means a higher system
load because the same data is scanned multiple times, although it
allows for a different conclusion each time.

The tradeoff between sa-exim and the other way are :
    1)  sa-exim reduces the amount of scanning done,
            less load on your system
    2)  sa-exim can't use per-recipient rules (see above)
    3)  sa-exim CAN _reject_ unacceptable content

The other method can NOT _reject_ unacceptable content.  Rejection
occurs during the SMTP conversation if your mail server does not
accept responsibility for the message and does not put it on the
queue.  In this scenario, the sending MTA is responsible for returning
a bounce to the sender.

This point is very important.  You can bounce messages after accepting
them, *however* this is not considered good practice because the
sender is usually forged.  This results in either your queue filling
up with undeliverable bounces (if the forged sender doesn't exist) or
you Joe-Job an innocent bystander who's address was used by the
forger.  (that is, you end up sending the spam or virus to someone

The only acceptable practice for handling inappropriate content after
it has been queued is to deliver it to a spam folder for the recipient
to inspect and identify 


The teaching of the wise is a fountain of life,
turning a man from the snares of death.
        Proverbs 13:14

Attachment: pgpYcuhacrXYj.pgp
Description: PGP signature

Reply to: