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 else) 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 HTH, -D -- The teaching of the wise is a fountain of life, turning a man from the snares of death. Proverbs 13:14 http://dman13.dyndns.org/~dman/
Attachment:
pgpYcuhacrXYj.pgp
Description: PGP signature