It won't matter in your situation if you let your mail delivery agent
figure it out.  There's an option in postfix called
"maildrop_destination_recipient_limit".  If you set this to 1, it scans
the message once, adds scores and modifies headers, then passes the
message 1 time for each recipient - this way it lets the mail delivery
agent handle the message.

Here's what I did to test this:

I run a postfix <-> amavis-new -> spamassassin configuration.  I run a
per-user white/black lists with per-user sa options in a mysql database. 
Postfix delivers the mail to my maildrop program and it reads the same
user prefs in mysql to determine what to do with the message.  Basically
SA only scores my message and adds headers when needed.

I configured my account ([EMAIL PROTECTED]) to allow messages with scores
of up to 15.0 and I whitelisted my "[EMAIL PROTECTED]" account.  I
configured another user ([EMAIL PROTECTED]) to block anything above a
3.0.  Here's my test message as it went through amavis:

Oct  7 13:06:36 IGMVmg004 amavisd[9073]: (09073-06) Passed,
<[EMAIL PROTECTED]> -> <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,
quarantine spam-336d47e3871db271a632649336b9ba9a-20041007-130636-09073-06,
Message-ID: <[EMAIL PROTECTED]>, Hits: 7.559 (Re: IT'S
FREE!) Content analysis details:   (7.6 points, 6.5 required), ,  3.2
DOMAIN_RATIO           BODY: Message body mentions many internet domains, 
0.0 BAYES_50               BODY: Bayesian spam probability is 40 to 60%,  
                          [score: 0.4718],  1.0 URIBL_SBL             
Contains an URL listed in the SBL blocklist,                            
[URIs: jzbsadzd.info],  0.4 URIBL_AB_SURBL         Contains an URL listed
in the AB SURBL blocklist,                             [URIs:
jzbsadzd.info],  1.5 URIBL_WS_SURBL         Contains an URL listed in the
WS SURBL blocklist,                             [URIs: jzbsadzd.info], 
3.2 URIBL_OB_SURBL         Contains an URL listed in the OB SURBL
blocklist,                             [URIs: jzbsadzd.info],  4.3
URIBL_SC_SURBL         Contains an URL listed in the SC SURBL blocklist,  
                          [URIs: jzbsadzd.info], -6.0 AWL                 
  AWL: From: address is in the auto white-list, ,
------------------------------------------------------------------------------

[EMAIL PROTECTED] got the message - spamhater didn't (it got quarantined
for him).  In my configuration, maildrop decided what to do - not SA.

Keith


> Matt :
>
> I use the postfix(MTA)+ amavisd+ S.Assassin solution. If I understood what
> you wrote its impossible to block it (based in my solution), is it ?
>
> Ps. If your answer is yes; could we consider it a S.Assassin?s flaw ?
>
>
> -----Mensagem original-----
> De: Matt Kettler [mailto:[EMAIL PROTECTED]
> Enviada em: quinta-feira, 7 de outubro de 2004 12:56
> Para: Daniel A. de Araujo; users@spamassassin.apache.org
> Assunto: Re: All_Spam_to question
>
>
> At 11:36 AM 10/7/2004, Daniel A. de Araujo wrote:
>>We are having a problem using the all_spam_to option.
>>When a message is sent to a list of users and at CCO field has a user
>>included at all_spam_to option, ALL users listed in the message, not only
>>the white-listed user will receive it.
>>Its very bad, because a Spammer who knows that a xxx@ user is
>> white-listed
>>can bypass the Anti-Spam system.
>>
>>Any ideias how to solve this ?
>
> Implement your whitelisting in whatever tool calls spamassassin, not in
> spamassassin itself. If you use procmail, this is pretty easy, it's just a
> procmail rule that avoids calling SA for that user, instead of calling it
> for all messages. If you use a milter, this is pretty tricky, or
> impossible, depending on the milter you use and how your MTA works.
>
> Since spamassassin views each message without any context of the message
> envelope, SA cannot (reliably) know who a message is going to be delivered
> to. Thus, it acts based on all the recipient addresses it sees in the
> message.
>
> Worse still, if you call SA at the MTA layer (ie: with a milter) there's
> only one message for SA to process, not one per recipient. At that point,
> it would be physically impossible for SA to handle things differently on a
> per-recipient basis, because there's only one message.
>
>
> As informações existentes nessa mensagem e nos arquivos anexados são para
> uso restrito, sendo seu sigilo protegido por lei. Caso não seja
> destinatário, saiba que leitura, divulgação ou cópia são proibidas.Favor
> apagar as informações e notificar

Reply via email to