3 Lines of Defense

[Ramon F Herrera <ra...@forcewise.com>]

After being away from system administration duties for a long time, I 
have returned. My current motivation is to bring down the SPAM in my 
private server.

These are the 3 lines of defense:

(1) Added the lines shown below to the file /etc/mail/sendmail.cf.

(2) *SpamAssassin*. Implemented this week. Currently running "sa-learn 
--spam" almost on a message by message basis. The results are very 
promising. I am considering migrating from procmail-based to 
MTA/sendmail-based. Somehow it seems that taking procmail out of the 
equation would result on a slightly more reliable system? Pros? Cons?

(3) My e-mail reader, Thunderbird. Every time I opened it had to spend a 
lot of time marking junk mail. That's when I decided to add SpamAssassin.

Due to the deluge of SPAM, my impression was that the spamhaus+spamcop 
combo was not working very well. However, upon closer inspection I 
noticed that about 7,000 messages are being rejected each week. BTW: I 
am guessing that spamhaus by itself is sufficient, since spamcop only 
rejected 3 messages that were missed by spamhaus.

Any comments, suggestions are most welcome.

TIA,

-Ramon F. Herrera

Re: 3 Lines of Defense

[Vincent Fox <vb...@ucdavis.edu>]

I had good success with greet pause set to 11 seconds.  Empirically 5 seconds made little difference, but I could see a marked reduction at anything above 10 seconds.  Longer than 15 didn’t give much further improvement though.

Sent from my iPhone

> On Sep 28, 2019, at 08:39, Grant Taylor <gt...@tnetconsulting.net> wrote:
> 
> On 9/27/19 2:11 PM, Ramon F Herrera wrote:
>> After being away from system administration duties for a long time, I have returned.
> 
> Welcome back.
> 
>> These are the 3 lines of defense:
>> (1) Added the lines shown below to the file /etc/mail/sendmail.cf.
> 
> I strongly recommend using the mc (m4) based configuration file.  You should easily be able to use the RBLs that way.
> 
> If you've been out of the Sendmail administration game long enough to not be familiar with the mc (m4) configuration method, I *STRONGLY* suggest (quickly) /read/ the README files from the Sendmail source distribution, particularly in the source directory and the cf/ sub-directory.  I'd also encourage you to /skim/ the current Sendmail Installation and Operations Guide as there have been a number of things added in the last 10+ years.
> 
>> (2) *SpamAssassin*. Implemented this week. Currently running "sa-learn --spam" almost on a message by message basis. The results are very promising. I am considering migrating from procmail-based to MTA/sendmail-based.
> 
> Sure.  That will allow Sendmail to actually /reject/ messages at SMTP time.
> 
>> Somehow it seems that taking procmail out of the equation would result on a slightly more reliable system? Pros? Cons?
> 
> IMHO they are mostly Pros with a few complications.
> 
> One thing you will need to deal with is that SpamAssassin via procmail inherently has access to the per-user information; user preferences, Bayesian training data, etc. because it's running as the receiving user.  Conversely, SpamAssassin via a milter does not have access to those /same/ per-user settings because it's running as a single user.  You can work around this by storing said per-user settings in a database that the SpamAssassin milter can be allowed access to.  It's not difficult. But you should be aware that you will very likely need to do so.
> 
> I would strongly recommend running SpamAssassin as a milter so that you can /reject/ messages at SMTP time.
> 
>> (3) My e-mail reader, Thunderbird. Every time I opened it had to spend a lot of time marking junk mail. That's when I decided to add SpamAssassin.
> 
> I have found that the combination of filtering techniques I run renders Thunderbird's junk filter largely useless.  I've told it to trust my server's SpamAssassin headers.
> 
>> Due to the deluge of SPAM, my impression was that the spamhaus+spamcop combo was not working very well. However, upon closer inspection I noticed that about 7,000 messages are being rejected each week. BTW: I am guessing that spamhaus by itself is sufficient, since spamcop only rejected 3 messages that were missed by spamhaus.
> 
> Don't trust those numbers as such.  There is a very good chance that SpamCop is rejecting messages that Spamhaus would reject if they made it past SpamCopy to Spamhaus.  Try swapping the order and getting new numbers before you decide to remove Spamhaus.
> 
>> Any comments, suggestions are most welcome.
> 
> Check out and consider doing the following things:
> 
> · NoListing — Provides similar functionality to grey listing without nearly as many undesired side effects.  (I'm not aware of any side effects.)
> · Junk Email Filter's Project Tarbaby — Intercepts the would be spammers that are targeting high order / backup MX servers which tend to not have the same level of filtering.
> · J.E.F.'s P.T. RBL — Leverage what Junk Email Filter has learned and filter out bad (non-RFC compliant) actors.  E.g. spam cannons that like to connect, send everything before getting the greeting banner, and then disconnect while the receiving end catches up.
> · Greet Pause — Enforce following SMTP protocol timing.  (See above.) (This is an mc (m4) option.)
> · Set a Bad RCPT Throttle — Slow down people that try to send invalid recipients to your server.  (This is an mc (m4) option.)
> · Run an SPF / DKIM / DMARC milter so that you can easily /reject/ messages at SMTP time if they are coming from somewhere that the purported sending domain didn't authorize.
> · Publish SPF / DKIM / DMARC information for your domain so that others can do the same type of filtering.  —  This is also becoming more and more important with some of the big players, especially for IPv6 where some of them are requiring newer and more strict rules.
> · Run a ClamAV milter.  (Same reasons for the other milters.)
> · Consider moving your RBLs from hard pass / fail in Sendmail to score based in SpamAssassin.  —  This will allow you to add to the spam score per RBL and require that the spam score be above a point to reject. This means that senders accidentally getting on one RBL doesn't guarantee that your server will reject them.  —  I find this flexibility to be helpful.
> 
> I can't guarantee that's all that I would recommend.  I just got up and am still drinking caffeine.  But those are the big things that are coming to mind to start with.
> 
> But running SpamAssassin via a milter at SMTP time?  Yes, do that.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 

Re: 3 Lines of Defense

[Grant Taylor <gt...@tnetconsulting.net>]

On 9/27/19 2:11 PM, Ramon F Herrera wrote:
> After being away from system administration duties for a long time, I 
> have returned.

Welcome back.

> These are the 3 lines of defense:
> 
> (1) Added the lines shown below to the file /etc/mail/sendmail.cf.

I strongly recommend using the mc (m4) based configuration file.  You 
should easily be able to use the RBLs that way.

If you've been out of the Sendmail administration game long enough to 
not be familiar with the mc (m4) configuration method, I *STRONGLY* 
suggest (quickly) /read/ the README files from the Sendmail source 
distribution, particularly in the source directory and the cf/ 
sub-directory.  I'd also encourage you to /skim/ the current Sendmail 
Installation and Operations Guide as there have been a number of things 
added in the last 10+ years.

> (2) *SpamAssassin*. Implemented this week. Currently running "sa-learn 
> --spam" almost on a message by message basis. The results are very 
> promising. I am considering migrating from procmail-based to 
> MTA/sendmail-based.

Sure.  That will allow Sendmail to actually /reject/ messages at SMTP time.

> Somehow it seems that taking procmail out of the equation would result 
> on a slightly more reliable system? Pros? Cons?

IMHO they are mostly Pros with a few complications.

One thing you will need to deal with is that SpamAssassin via procmail 
inherently has access to the per-user information; user preferences, 
Bayesian training data, etc. because it's running as the receiving user. 
  Conversely, SpamAssassin via a milter does not have access to those 
/same/ per-user settings because it's running as a single user.  You can 
work around this by storing said per-user settings in a database that 
the SpamAssassin milter can be allowed access to.  It's not difficult. 
But you should be aware that you will very likely need to do so.

I would strongly recommend running SpamAssassin as a milter so that you 
can /reject/ messages at SMTP time.

> (3) My e-mail reader, Thunderbird. Every time I opened it had to spend a 
> lot of time marking junk mail. That's when I decided to add SpamAssassin.

I have found that the combination of filtering techniques I run renders 
Thunderbird's junk filter largely useless.  I've told it to trust my 
server's SpamAssassin headers.

> Due to the deluge of SPAM, my impression was that the spamhaus+spamcop 
> combo was not working very well. However, upon closer inspection I 
> noticed that about 7,000 messages are being rejected each week. BTW: I 
> am guessing that spamhaus by itself is sufficient, since spamcop only 
> rejected 3 messages that were missed by spamhaus.

Don't trust those numbers as such.  There is a very good chance that 
SpamCop is rejecting messages that Spamhaus would reject if they made it 
past SpamCopy to Spamhaus.  Try swapping the order and getting new 
numbers before you decide to remove Spamhaus.

> Any comments, suggestions are most welcome.

Check out and consider doing the following things:

  · NoListing — Provides similar functionality to grey listing without 
nearly as many undesired side effects.  (I'm not aware of any side effects.)
  · Junk Email Filter's Project Tarbaby — Intercepts the would be 
spammers that are targeting high order / backup MX servers which tend to 
not have the same level of filtering.
  · J.E.F.'s P.T. RBL — Leverage what Junk Email Filter has learned and 
filter out bad (non-RFC compliant) actors.  E.g. spam cannons that like 
to connect, send everything before getting the greeting banner, and then 
disconnect while the receiving end catches up.
  · Greet Pause — Enforce following SMTP protocol timing.  (See above.) 
(This is an mc (m4) option.)
  · Set a Bad RCPT Throttle — Slow down people that try to send invalid 
recipients to your server.  (This is an mc (m4) option.)
  · Run an SPF / DKIM / DMARC milter so that you can easily /reject/ 
messages at SMTP time if they are coming from somewhere that the 
purported sending domain didn't authorize.
  · Publish SPF / DKIM / DMARC information for your domain so that 
others can do the same type of filtering.  —  This is also becoming more 
and more important with some of the big players, especially for IPv6 
where some of them are requiring newer and more strict rules.
  · Run a ClamAV milter.  (Same reasons for the other milters.)
  · Consider moving your RBLs from hard pass / fail in Sendmail to score 
based in SpamAssassin.  —  This will allow you to add to the spam score 
per RBL and require that the spam score be above a point to reject. 
This means that senders accidentally getting on one RBL doesn't 
guarantee that your server will reject them.  —  I find this flexibility 
to be helpful.

I can't guarantee that's all that I would recommend.  I just got up and 
am still drinking caffeine.  But those are the big things that are 
coming to mind to start with.

But running SpamAssassin via a milter at SMTP time?  Yes, do that.



-- 
Grant. . . .
unix || die

Re: 3 Lines of Defense

[Matus UHLAR - fantomas <uh...@fantomas.sk>]

On 27.09.19 15:11, Ramon F Herrera wrote:
>After being away from system administration duties for a long time, I 
>have returned. My current motivation is to bring down the SPAM in my 
>private server.
>
>These are the 3 lines of defense:
>
>(1) Added the lines shown below to the file /etc/mail/sendmail.cf.

don't you use m4?

>(2) *SpamAssassin*. Implemented this week. Currently running "sa-learn 
>--spam" almost on a message by message basis. The results are very 
>promising. I am considering migrating from procmail-based to 
>MTA/sendmail-based. Somehow it seems that taking procmail out of the 
>equation would result on a slightly more reliable system? Pros? Cons?

what do you mean MTA/sendmail-based? spamass-milter?

>(3) My e-mail reader, Thunderbird. Every time I opened it had to spend 
>a lot of time marking junk mail. That's when I decided to add 
>SpamAssassin.
>
>Due to the deluge of SPAM, my impression was that the spamhaus+spamcop 
>combo was not working very well. However, upon closer inspection I 
>noticed that about 7,000 messages are being rejected each week. BTW: I 
>am guessing that spamhaus by itself is sufficient, since spamcop only 
>rejected 3 messages that were missed by spamhaus.

that's mostly because clients rejected by spamcop were already rejected by
spamhaus.

btw I have very good experience with FEATURE(`greet_pause', `6000')

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The early bird may get the worm, but the second mouse gets the cheese.