configure spamassassin to only check incoming email

[Gijs]

Hey list,

I'm using sendmail to handle all my incoming and outgoing email and now 
I've ran into a problem related to spamassassin.
Because spamassassin also checks outgoing mail, sending outgoing mails 
always takes about 3-4 seconds.
Normally this wouldn't be a problem, but my boss wants to send a 
newsletter every month to quite a number of users, and this is undoable 
if it takes 3-4 seconds per email.

I've tested it without spamassassin and it only took like 0.3-0.5 
seconds, which is doable.

Another solution to my problem is ok as well, as long as the send-time 
gets decreased to around <0.5 seconds.

Regards,
Gijs

[Gijs]

Steven Stern wrote:
>  On 05/31/2008 08:12 AM, Gijs wrote:
>  | Mike Burger wrote:
>  |>> Hey list,
>  |>>
>  |>> I'm using sendmail to handle all my incoming and outgoing email 
>  and now
>  |>> I've ran into a problem related to spamassassin.
>  |>> Because spamassassin also checks outgoing mail, sending outgoing mails
>  |>> always takes about 3-4 seconds.
>  |>> Normally this wouldn't be a problem, but my boss wants to send a
>  |>> newsletter every month to quite a number of users, and this is 
>  undoable
>  |>> if it takes 3-4 seconds per email.
>  |>>
>  |>> I've tested it without spamassassin and it only took like 0.3-0.5
>  |>> seconds, which is doable.
>  |>>
>  |>> Another solution to my problem is ok as well, as long as the send-time
>  |>> gets decreased to around <0.5 seconds.
>  |>>
>  |>
>  |> It all revolves around how you've implemented SA.  While it is
>  possible to
>  |> use it in a milter style fashion, the more common way is to run
>  spamd, and
>  |> call spamc from procmail, at delivery time.
>  |>
>  |> Noting that if your local PCs have been compromised, and are now part
>  of a
>  |> botnet, they're not going to send their spam out through your mail
>  server,
>  |> anyhow, it might be simpler to run via procmail at delivery, and bypass
>  |> scanning outbound mail.
>  |>
>  |>
>  | I know my way around in Linux but how mail is dealt with internally, I
>  | have no clue whatsoever.
>  | I've added the following line to the configuration of sendmail, so that
>  | it works with spamassassin:
>  | INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock,
>  | F=,T=C:15m;S:4m;R:4m;E:10m')
>  |
>  | Apart from that, spamass-milter is running with the following command:
>  | spamass-milter -p /var/run/spamass.sock -f -b spam(a)xxxx.com
>  |
>  | And spamd is ran like this:
>  | /usr/bin/spamd -d -c -a -s local6 -u spam
>  |
>  | Maybe an easier way is to change the sendmail command PHP uses, since
>  | the script that sends out all the emails makes use of PHP.
>  | It would be enough for me to change the PHP standard sendmail command to
>  | bypass spamassassin.
>  | Hope this sheds some more light on my situation.
>  |
>
>  You need to tell spamass-milter to ignore locally generated mail:
>
>  spamass-milter -p /var/run/spamass.sock -f -b spam(a)xxxx.com -i 127.0.0.1
>
>  You may wish to add other network addresses as a list following "-i", 
>  e.g.,
>  ~    -i 127.0.0.1,10.0.0.0/8
>  
Well, this seems to have done the trick. Thanks a lot!
I've already tried to ignore 127.0.0.1 inside the configuration of 
spamassassin.
But when I tried that, spamassassin analyses the mail to see if it 
matches 127.0.0.1 and already takes up a lot of time.
The solution you provided brought the delay down to a little less than a 
second, which should be doable.

Thanks again :)

[Tim]

On Sat, 2008-05-31 at 18:46 -0400, Mike Burger wrote:
>  unless there's a way to bypass the milter for outbound mail, or
> you
>  move away from the milter for spamassassin, I can't think of a way
>  around your situation. 
Using a different SMTP server for that task?

-- 
[tim@localhost ~]$ uname -r
2.6.25.3-18.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.

[Mike Burger]

>  Mike Burger wrote:
> >> Hey list,
> >>
> >> I'm using sendmail to handle all my incoming and outgoing email and now
> >> I've ran into a problem related to spamassassin.
> >> Because spamassassin also checks outgoing mail, sending outgoing mails
> >> always takes about 3-4 seconds.
> >> Normally this wouldn't be a problem, but my boss wants to send a
> >> newsletter every month to quite a number of users, and this is undoable
> >> if it takes 3-4 seconds per email.
> >>
> >> I've tested it without spamassassin and it only took like 0.3-0.5
> >> seconds, which is doable.
> >>
> >> Another solution to my problem is ok as well, as long as the send-time
> >> gets decreased to around <0.5 seconds.
> >>
> >
> > It all revolves around how you've implemented SA.  While it is possible
> > to
> > use it in a milter style fashion, the more common way is to run spamd,
> > and
> > call spamc from procmail, at delivery time.
> >
> > Noting that if your local PCs have been compromised, and are now part of
> > a
> > botnet, they're not going to send their spam out through your mail
> > server,
> > anyhow, it might be simpler to run via procmail at delivery, and bypass
> > scanning outbound mail.
> >
> >
>  I know my way around in Linux but how mail is dealt with internally, I
>  have no clue whatsoever.
>  I've added the following line to the configuration of sendmail, so that
>  it works with spamassassin:
>  INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock,
>  F=,T=C:15m;S:4m;R:4m;E:10m')
>
>  Apart from that, spamass-milter is running with the following command:
>  spamass-milter -p /var/run/spamass.sock -f -b spam(a)xxxx.com
>
>  And spamd is ran like this:
>  /usr/bin/spamd -d -c -a -s local6 -u spam
>
>  Maybe an easier way is to change the sendmail command PHP uses, since
>  the script that sends out all the emails makes use of PHP.
>  It would be enough for me to change the PHP standard sendmail command to
>  bypass spamassassin.
>  Hope this sheds some more light on my situation. 
Well, you folks are using it via milter...unless there's a way to bypass
the milter for outbound mail, or you move away from the milter for
spamassassin, I can't think of a way around your situation.

Sorry.

-- 
Mike Burger
http://www.bubbanfriends.org

Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org

To be notified of updates to the web site, visit:

https://www.bubbanfriends.org/mailman/listinfo/site-update

or send a blank email message to:

site-update-subscribe(a)bubbanfriends.org

[SternData]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/31/2008 08:12 AM, Gijs wrote:
| Mike Burger wrote:
|>> Hey list,
|>>
|>> I'm using sendmail to handle all my incoming and outgoing email and now
|>> I've ran into a problem related to spamassassin.
|>> Because spamassassin also checks outgoing mail, sending outgoing mails
|>> always takes about 3-4 seconds.
|>> Normally this wouldn't be a problem, but my boss wants to send a
|>> newsletter every month to quite a number of users, and this is undoable
|>> if it takes 3-4 seconds per email.
|>>
|>> I've tested it without spamassassin and it only took like 0.3-0.5
|>> seconds, which is doable.
|>>
|>> Another solution to my problem is ok as well, as long as the send-time
|>> gets decreased to around <0.5 seconds.
|>>
|>
|> It all revolves around how you've implemented SA.  While it is
possible to
|> use it in a milter style fashion, the more common way is to run
spamd, and
|> call spamc from procmail, at delivery time.
|>
|> Noting that if your local PCs have been compromised, and are now part
of a
|> botnet, they're not going to send their spam out through your mail
server,
|> anyhow, it might be simpler to run via procmail at delivery, and bypass
|> scanning outbound mail.
|>
|>
| I know my way around in Linux but how mail is dealt with internally, I
| have no clue whatsoever.
| I've added the following line to the configuration of sendmail, so that
| it works with spamassassin:
| INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock,
| F=,T=C:15m;S:4m;R:4m;E:10m')
|
| Apart from that, spamass-milter is running with the following command:
| spamass-milter -p /var/run/spamass.sock -f -b spam(a)xxxx.com
|
| And spamd is ran like this:
| /usr/bin/spamd -d -c -a -s local6 -u spam
|
| Maybe an easier way is to change the sendmail command PHP uses, since
| the script that sends out all the emails makes use of PHP.
| It would be enough for me to change the PHP standard sendmail command to
| bypass spamassassin.
| Hope this sheds some more light on my situation.
|

You need to tell spamass-milter to ignore locally generated mail:

spamass-milter -p /var/run/spamass.sock -f -b spam(a)xxxx.com -i 127.0.0.1

You may wish to add other network addresses as a list following "-i", e.g.,
~    -i 127.0.0.1,10.0.0.0/8

- --

~  Steve
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhBXewACgkQeERILVgMyvBYLQCfQrSWdemBCrhmF5eXkaG6ohtr
> gnkAnAnrBRE0hrqdLmNj8vU+pcSxpvS8
> =Ig1N
> -----END PGP SIGNATURE-----

[Gijs]

Mike Burger wrote:
> > Hey list,
> >
> > I'm using sendmail to handle all my incoming and outgoing email and now
> > I've ran into a problem related to spamassassin.
> > Because spamassassin also checks outgoing mail, sending outgoing mails
> > always takes about 3-4 seconds.
> > Normally this wouldn't be a problem, but my boss wants to send a
> > newsletter every month to quite a number of users, and this is undoable
> > if it takes 3-4 seconds per email.
> >
> > I've tested it without spamassassin and it only took like 0.3-0.5
> > seconds, which is doable.
> >
> > Another solution to my problem is ok as well, as long as the send-time
> > gets decreased to around <0.5 seconds.
> >     
>
>  It all revolves around how you've implemented SA.  While it is possible to
>  use it in a milter style fashion, the more common way is to run spamd, and
>  call spamc from procmail, at delivery time.
>
>  Noting that if your local PCs have been compromised, and are now part of a
>  botnet, they're not going to send their spam out through your mail server,
>  anyhow, it might be simpler to run via procmail at delivery, and bypass
>  scanning outbound mail.
>
>     
I know my way around in Linux but how mail is dealt with internally, I 
have no clue whatsoever.
I've added the following line to the configuration of sendmail, so that 
it works with spamassassin:
INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, 
F=,T=C:15m;S:4m;R:4m;E:10m')

Apart from that, spamass-milter is running with the following command:
spamass-milter -p /var/run/spamass.sock -f -b spam(a)xxxx.com

And spamd is ran like this:
/usr/bin/spamd -d -c -a -s local6 -u spam

Maybe an easier way is to change the sendmail command PHP uses, since 
the script that sends out all the emails makes use of PHP.
It would be enough for me to change the PHP standard sendmail command to 
bypass spamassassin.
Hope this sheds some more light on my situation.

[Mike Burger]

>  Hey list,
>
>  I'm using sendmail to handle all my incoming and outgoing email and now
>  I've ran into a problem related to spamassassin.
>  Because spamassassin also checks outgoing mail, sending outgoing mails
>  always takes about 3-4 seconds.
>  Normally this wouldn't be a problem, but my boss wants to send a
>  newsletter every month to quite a number of users, and this is undoable
>  if it takes 3-4 seconds per email.
>
>  I've tested it without spamassassin and it only took like 0.3-0.5
>  seconds, which is doable.
>
>  Another solution to my problem is ok as well, as long as the send-time
>  gets decreased to around <0.5 seconds. 
It all revolves around how you've implemented SA.  While it is possible to
use it in a milter style fashion, the more common way is to run spamd, and
call spamc from procmail, at delivery time.

Noting that if your local PCs have been compromised, and are now part of a
botnet, they're not going to send their spam out through your mail server,
anyhow, it might be simpler to run via procmail at delivery, and bypass
scanning outbound mail.

-- 
Mike Burger
http://www.bubbanfriends.org

Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org

To be notified of updates to the web site, visit:

https://www.bubbanfriends.org/mailman/listinfo/site-update

or send a blank email message to:

site-update-subscribe(a)bubbanfriends.org