Setting Blacklist_from and whitelist_to

[damuz <ma...@damuz.idps.co.uk>]

Hi all.

I've very recently had the problem of sorting out my work's email spam
dropped on my lap and to be honest, I know a little but a little knowledge
can be a dangerous thing...

Anyhow.

Having spent the last few days making as sure as I can be that the network
and exchange is all up to date I'm now looking at our email hosting and
seeing what can be done there to cut things down a bit.
Enabling the spamassassin (which was turned off) has improved things a
little but considering how configurable and flexible it seems to be, I had a
couple of thoughts which I was wondering if anyone can shed some light on as
to whether it might be a good idea or no.

Alot of the spam we're receiving is spoofed so initally I wondered (and
tried, just to see what would happen) if I added our own domain to the
blacklist. Since all our domain mail is internal I figured anything coming
from outside couldn't be 'from' us and therefore could be legitimately
blocked.

Unsurprisingly his did stop a chunk of spam but I was wondering if there
might be any problems with this approach?

Secondly, it occurred to me that all the (legit) mail to us will only be to
a handful of email addresses and much of the spam still getting through is
sent to spurious recipients@mydomain.com.
So with this in mind, is it useful or advisable to setup those legit email
addresses as " whitelist_to " and if so, what becomes of the 'rest' of the
mail or do you have to define only receive to whitelist_to?

Sorry if it seems a little confusing! 

Many thanks.
  

-- 
View this message in context: http://old.nabble.com/Setting-Blacklist_from-and-whitelist_to-tp27735054p27735054.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Setting Blacklist_from and whitelist_to

[damuz <ma...@damuz.idps.co.uk>]

Karsten Bräckelmann-2 wrote:
> 
> 
> Since you didn't get back to this part, to translate it: Do not use
> catch-all.
> 
> What I recall from your initial post, I also wondered whether you are
> accepting *all* messages to *any* address, including non-existent ones.
> Catch-all.
> 
> If you do, don't. But accept mail for existing users only in your MX
> SMTP. That alone will cut down the spam load significantly.
> 
> 

This does support what I was thinking would be the obvious solution, i.e.
accept only to actual mail addresses within the domain, as mentioned in the
OP, but better to do it with MX records than SA.
Having found the MX records now it would seem that currently it's configured
to 'catch all'.
Will do a bit more reading and make some changes.



-- 
View this message in context: http://old.nabble.com/Setting-Blacklist_from-and-whitelist_to-tp27735054p27738584.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Setting Blacklist_from and whitelist_to

[Karsten Bräckelmann <gu...@rudersport.de>]

On Sun, 2010-02-28 at 12:13 -0800, an anonymous Nabble user wrote:
> Martin Gregorie wrote:

> > It would be better to let the MTA reject unknown users as part of
> > pre-queue processing because that puts less processing load on the main
> > chain. Do you have enough access to do this?

Since you didn't get back to this part, to translate it: Do not use
catch-all.

What I recall from your initial post, I also wondered whether you are
accepting *all* messages to *any* address, including non-existent ones.
Catch-all.

If you do, don't. But accept mail for existing users only in your MX
SMTP. That alone will cut down the spam load significantly.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: Setting Blacklist_from and whitelist_to

[Martin Gregorie <ma...@gregorie.org>]

On Sun, 2010-02-28 at 12:13 -0800, damuz wrote:
> 
> 
> Martin Gregorie-2 wrote:
> > 
> > 
> > How is SA used by your hosted email MTA, IOW is Spamassasin called in
> > pre-queue before the mail has been accepted or is it called later? 
> > 
> > How much control do you have over that server? Can you set up
> > grey-listing for your domain on it?
> > 
> > If you're getting much backscatter (remote MTAs sending 'unknown user'
> > rejections for mail with a forged sender), consider setting up an SPF
> > record for your domain. Well-behaved remote MTAs will use it to check
> > for forged senders and not send the rejections if the sender was forged.
> > 
> > It would be better to let the MTA reject unknown users as part of
> > pre-queue processing because that puts less processing load on the main
> > chain. Do you have enough access to do this?
> > 
> > 
> > Martin
> > 
> > 
> 
> I'll answer as best as I know.  
> Our network runs SBS2003 and Exchange deals with the outgoing mail and
> collects it from the hosting company which also hold the website.
> SA is configurable from the hosting sites  Cpanel (web login) and I'm
> assuming that as it 'tags' and 'scores' the mail that Exchange then
> downloads, that it is called in after the mail has already been accepted. I
> don't really know.
> 
My point was that rejecting mail for unknown users on your site is best
done by the hosting MTA, not SA. This means that you need access to the
MTA configuration, rather than the SA configuration. Once mail has been
accepted by the hosting MTA you can only deliver it or throw it in a bit
bucket. You should *not* reject it at this stage or you become part of
the junk mail problem.

Grey-listing: I'm using a similar set-up to you. My mail is accepted by
my ISP's smarthost and passed to my private MTA for delivery. The only
difference is that I run SA rather than my ISP. About a year ago my ISP
turned on grey-listing and overnight spam dropped from 70% of incoming
mail to less than 10%. IME its A Good Thing, but you need to persuade
your email hosting organisation to implement it because its a front end
for the hosting MTA you're using.

HTH
Martin

Re: Setting Blacklist_from and whitelist_to

[damuz <ma...@damuz.idps.co.uk>]

Martin Gregorie-2 wrote:
> 
> 
> How is SA used by your hosted email MTA, IOW is Spamassasin called in
> pre-queue before the mail has been accepted or is it called later? 
> 
> How much control do you have over that server? Can you set up
> grey-listing for your domain on it?
> 
> If you're getting much backscatter (remote MTAs sending 'unknown user'
> rejections for mail with a forged sender), consider setting up an SPF
> record for your domain. Well-behaved remote MTAs will use it to check
> for forged senders and not send the rejections if the sender was forged.
> 
> It would be better to let the MTA reject unknown users as part of
> pre-queue processing because that puts less processing load on the main
> chain. Do you have enough access to do this?
> 
> 
> Martin
> 
> 

I'll answer as best as I know.  
Our network runs SBS2003 and Exchange deals with the outgoing mail and
collects it from the hosting company which also hold the website.
SA is configurable from the hosting sites  Cpanel (web login) and I'm
assuming that as it 'tags' and 'scores' the mail that Exchange then
downloads, that it is called in after the mail has already been accepted. I
don't really know.

As to control over various settings for SA, the configuration panel is very
basic but I have access to the .configuration file if things need to be
changed in more detail.
As to whether I have access enough to setup grey-listing again, I'm sorry I
don't know.

David


David
-- 
View this message in context: http://old.nabble.com/Setting-Blacklist_from-and-whitelist_to-tp27735054p27737705.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Setting Blacklist_from and whitelist_to

[Martin Gregorie <ma...@gregorie.org>]

On Sun, 2010-02-28 at 05:50 -0800, damuz wrote:

> Having spent the last few days making as sure as I can be that the network
> and exchange is all up to date I'm now looking at our email hosting and
> seeing what can be done there to cut things down a bit.
>
> Enabling the spamassassin (which was turned off) has improved things a
> little but considering how configurable and flexible it seems to be, I had a
> couple of thoughts which I was wondering if anyone can shed some light on as
> to whether it might be a good idea or no.
> 
> Alot of the spam we're receiving is spoofed so initally I wondered (and
> tried, just to see what would happen) if I added our own domain to the
> blacklist. Since all our domain mail is internal I figured anything coming
> from outside couldn't be 'from' us and therefore could be legitimately
> blocked.
> 
How is SA used by your hosted email MTA, IOW is Spamassasin called in
pre-queue before the mail has been accepted or is it called later? 

How much control do you have over that server? Can you set up
grey-listing for your domain on it?

If you're getting much backscatter (remote MTAs sending 'unknown user'
rejections for mail with a forged sender), consider setting up an SPF
record for your domain. Well-behaved remote MTAs will use it to check
for forged senders and not send the rejections if the sender was forged.


> Unsurprisingly his did stop a chunk of spam but I was wondering if there
> might be any problems with this approach?
> 
It would be better to let the MTA reject unknown users as part of
pre-queue processing because that puts less processing load on the main
chain. Do you have enough access to do this?


Martin

Re: Setting Blacklist_from and whitelist_to

[Matt Kettler <mk...@verizon.net>]

On 2/28/2010 8:50 AM, damuz wrote:
> Hi all.
>
> I've very recently had the problem of sorting out my work's email spam
> dropped on my lap and to be honest, I know a little but a little knowledge
> can be a dangerous thing...
>
> Anyhow.
>
> Having spent the last few days making as sure as I can be that the network
> and exchange is all up to date I'm now looking at our email hosting and
> seeing what can be done there to cut things down a bit.
> Enabling the spamassassin (which was turned off) has improved things a
> little but considering how configurable and flexible it seems to be, I had a
> couple of thoughts which I was wondering if anyone can shed some light on as
> to whether it might be a good idea or no.
>
> Alot of the spam we're receiving is spoofed so initally I wondered (and
> tried, just to see what would happen) if I added our own domain to the
> blacklist. Since all our domain mail is internal I figured anything coming
> from outside couldn't be 'from' us and therefore could be legitimately
> blocked.
>
> Unsurprisingly his did stop a chunk of spam but I was wondering if there
> might be any problems with this approach?
>
> Secondly, it occurred to me that all the (legit) mail to us will only be to
> a handful of email addresses and much of the spam still getting through is
> sent to spurious recipients@mydomain.com.
> So with this in mind, is it useful or advisable to setup those legit email
> addresses as " whitelist_to " and if so, what becomes of the 'rest' of the
> mail or do you have to define only receive to whitelist_to?
>
> Sorry if it seems a little confusing! 
>
> Many thanks.
>   
>
>   

As someone else suggested, it would be many times better to handle this
in your MTA this:
    1) saves a LOT of cpu cycles having SA scan the message. Even if you
use shortcircuit, calling spamc, passing data to spamd, and parsing the
headers takes cpu time to do.
    2) saves bandwidth, because you can reject the message before the
DATA phase of the SMTP transaction. The message is never sent, so you're
not wasting your network pipe transfering it.

As for SpamAssassin's white/blacklist commands, these tools are VERY
crude, and very simple. They are just implemented as rules that shift
the message score. A quick summary follows (using 3.3's scoring, which I
believe to be the same as all versions from 2.6x forward, with the
exception of some options not being present in old versions...)

"From" based clauses:

Anything matching a blacklist_from clause gets +100 points tacked on to
the message score by a rule. (USER_IN_BLACKLIST)
Anything matching a whitelist_from or whitelist_from_rcvd clause gets
-100 points tacked on to the message score by a rule. (USER_IN_WHITELIST)
Anything matching a whitelist_from_spf clause gets -100 points tacked on
to the message score by a rule. (USER_IN_WHITELIST)
Anything matching a whitelist_from_dkim clause gets -100 points tacked
on to the message score by a rule. (USER_IN_DKIM_WHITELIST)

"To" based clauses
Anything matching a blacklist_to clause gets +10 points tacked on to the
message score by a rule. (USER_IN_BLACKLIST_TO)
Anything matching a whitelist_to clause gets -6 points tacked on to the
message score by a rule. (USER_IN_WHITELIST_TO)
Anything matching a more_spam_to clause gets -20 points tacked onto the
message score by a rule (USER_IN_MORE_SPAM_TO)
Anything matching a all_spam_to clause gets -100  points tacked onto the
message score by a rule (USER_IN_ALL_SPAM_TO)

there are a few more variants, but these are the common ones.
note: All of this assumes you haven't changed the scores of the
underlying rules, ie: score USER_IN_BLACKLIST 50.0


 
 

Re: [sa] Setting Blacklist_from and whitelist_to

[Charles Gregory <cg...@hwcn.org>]

On Sun, 28 Feb 2010, damuz wrote:
> Secondly, it occurred to me that all the (legit) mail to us will only be to
> a handful of email addresses and much of the spam still getting through is
> sent to spurious recipients@mydomain.com.
> So with this in mind, is it useful or advisable to setup those legit email
> addresses as " whitelist_to " and if so, what becomes of the 'rest' of the
> mail or do you have to define only receive to whitelist_to?

You have to 'fine tune' this kind of test. Keep in mind that the visible 
'To:' header is hardly more than a *comment* on the mail. It may contain 
a mailing list name, or another *valid* recipient on another domain, 
while the mail was sent to *your* domain as a 'Bcc' hidden recipient.

At the first stage of the SMTP transaction your MTA (should have) already 
rejected any mail that was actually 'addressed' to an invalid address.
So the issue you are dealing with can be described as 'mail to a 
legitimate recipient with a suspicious To: header'.

So it quickly devolves to the fact that the *only* thing you can reject is 
mail that has a 'To:' address that is @your.domain but which is not a 
valid (now or at any time in the past!) recipient on your domain. You 
can't flag mail that is 'To:' another domain. That could be valid!

Now you need to be careful that when you invoke a 'whitelist' you do so 
for the 'To:' header, and NOT for the envelope recipient, which, by 
definition will always be a 'hit'. Unfortunately, the standard 
'whitelist_to' will 'hit' on any embedded headers that your MTA adds to 
show the envelope recipient. You could essentially end up whitelisting all 
mail. So you need to whitelist on the visible headers *manually*....

So, if your list of internal recipients is not overly large, you may want 
to try the following:

header  __VALID_MYDOMAIN  ToCc =~ /(validuser1|validuser2|...)\@yourdomain.com/i
header  __TO_MYDOMAIN  ToCc =~ /\@yourdomain.com/i
meta     LOC_INVALID_MYDOMAIN ( __TO_MYDOMAIN && ( ! __VALID_MYDOMAIN ) )
describe LOC_INVALID_MYDOMAIN Address in To or Cc header to invalid address on our domain
score    LOC_INVALID_MYDOMAIN 1

Obivously, score modestly until we are sure there are no false positives. 
The big 'problem' with this scheme is that *any* change to the list of 
valid users requires the first rule to be updated. So I only recommend 
this approach if you have absolute control over your mail system.

- Charles