16 Feb
2014
16 Feb
'14
3:13 p.m.
FYI: This isn't for my Bitfolk server, but one I have hosted elsewhere.
My home server is unable to connect to my primary mail server currently:
"421 Too many concurrent SMTP connections".
This is due to spammers who are literally spamming my primary mail
server so hard I can't send mail to it (9,472 spam messages rejected by
my server so far today as at 15:10). I had similar issues towards the
end of January: http://www.solutium.net/images/jan2014_spam_rejects.png
I do have some basic rules in Exim to reject based on SMTP protocol
violations (no stats on that unfortunately), but most of my spam
rejection is based on Spamassassin processing the email. I have
increased --max-children to 10, but am still getting "prefork: server
reached --max-children setting, consider raising it" in the logs, but am
now also getting other errors, e.g.:
Feb 16 12:21:55 quartz spamd[4090]: check: exceeded time limit in
Mail::SpamAssassin::Plugin::Check::_eval_tests_type11_prineg400_set3, skipping further
tests
Feb 16 12:21:56 quartz spamd[4119]: rules: failed to run BAYES_99 test, skipping:
Feb 16 12:21:56 quartz spamd[4104]: rules: failed to run BAYES_99 test, skipping:
Feb 16 12:21:56 quartz spamd[4104]: (__alarm__ignore__(10480)
Feb 16 12:21:56 quartz spamd[4119]: (__alarm__ignore__(10493)
and
Feb 16 12:41:28 quartz spamd[4090]: Issuing rollback() due to DESTROY without explicit
disconnect() of DBD::mysql::db handle sa_bayes:localhost at
/usr/share/perl5/Mail/SpamAssassin/Plugin/Bayes.pm line 1516, <GEN4204> line 2.
Can any one provide some hints for IPTables rules or Exim config to rate
limit my SMTP ports without interfering too much with normal mail
operations? Alternatively, any suggestions to help Spamassassin process
quicker/better?
On the Spamassassin side, I have shortcircuiting turned on (see below).
The server has 4GB RAM (free output below).
# free
total used free shared buffers cached
Mem: 4127104 3537512 589592 0 161452 2253820
-/+ buffers/cache: 1122240 3004864
Swap: 3903784 143636 3760148
# Some shortcircuiting, if the plugin is enabled
#
ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
#
# default: strongly-whitelisted mails are *really* whitelisted now, if the
# shortcircuiting plugin is active, causing early exit to save CPU load.
# Uncomment to turn this on
#
shortcircuit USER_IN_WHITELIST on
shortcircuit USER_IN_DEF_WHITELIST on
shortcircuit USER_IN_ALL_SPAM_TO on
shortcircuit SUBJECT_IN_WHITELIST on
# the opposite; blacklisted mails can also save CPU
#
shortcircuit USER_IN_BLACKLIST on
shortcircuit USER_IN_BLACKLIST_TO on
shortcircuit SUBJECT_IN_BLACKLIST on
# if you have taken the time to correctly specify your "trusted_networks",
# this is another good way to save CPU
#
# shortcircuit ALL_TRUSTED on
# and a well-trained bayes DB can save running rules, too
#
# shortcircuit BAYES_99 spam
shortcircuit BAYES_00 ham
Thanks
Gavin
16 Feb
16 Feb
3:28 p.m.
Hi,
Can any one provide some hints for IPTables rules or
Exim config to rate
limit my SMTP ports without interfering too much with normal mail
operations? Alternatively, any suggestions to help Spamassassin process
quicker/better?
Just firewall everything for 12 hours. If that's not enough to encourage
the spammers to give up then you can probably extend it a little more
without having any remote mailservers bounce messages.
During this time, legitimate mail should queue on the sending host and
be retried for anywhere between 24 and 72 hours.
Just make sure you hide the mail server in such a way as it generates a
temporary error on the sending side rather than a permanent one.
Regards,
@ndy
--
andyjpb(a)ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
8:52 p.m.
On Sun, Feb 16, 2014 at 03:13:44PM +0000, Gavin Westwood wrote:
[...]
Can any one provide some hints for IPTables rules or Exim config to rate
limit my SMTP ports without interfering too much with normal mail
operations? Alternatively, any suggestions to help Spamassassin process
quicker/better?
[...]
Not for SpamAssassin, but have you thought about using one of the RBLs?
Then you'd block potential junk before you start spending CPU time on
bayes filtering.
Alternatively, you could try greylising, 4xx the sending mail server IP
for thirty minutes on the first mail seen from it, then allow it. Often
this helps as most exploited spam sources don't queue.
--
Best regards,
Ed http://www.s5h.net/
9:53 p.m.
I think the only answer is a good multilayered approach. Use a couple of
good RBLs. Then make sure you are doing all the checks on headers etc. Then
into spamassassin. The next step is to use fail2ban, so that any particular
IP can only be used by them a couple of times before being blocked at the
firewall. This has limited usefulness tbh, because they are not using their
own machines. What I have done is to research addresses and found that
there are certain ISPs that keep appearing in spam but not ham. I then log
and block them.
It is a bit time intensive the last steps, As always, it's a trade-off
On 16 February 2014 20:52, ed <ed-bitfolk(a)s5h.net> wrote:
On Sun, Feb 16, 2014 at 03:13:44PM +0000, Gavin
Westwood wrote:
--
Keith Williams
Keith's Place www.keiths-place.co.uk
Tailor Made English www.tmenglish.org
West Norfolk RSPCA www.westnorfolkrspca.org.uk
[...]
Can any one provide some hints for IPTables rules or Exim config to rate
limit my SMTP ports without interfering too much with normal mail
operations? Alternatively, any suggestions to help Spamassassin process
quicker/better?
[...]
Not for SpamAssassin, but have you thought about using one of the RBLs?
Then you'd block potential junk before you start spending CPU time on
bayes filtering.
Alternatively, you could try greylising, 4xx the sending mail server IP
for thirty minutes on the first mail seen from it, then allow it. Often
this helps as most exploited spam sources don't queue.
--
Best regards,
Ed http://www.s5h.net/
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
11:45 p.m.
ed said:
Alternatively, you could try greylising, 4xx the
sending mail server IP
for thirty minutes on the first mail seen from it, then allow it. Often
this helps as most exploited spam sources don't queue.
Greylisting is my solution. So little gets past it that I don't bother
with spamassassin. Occasionally, a handful come via a spammer who does
follow RFCs, but Thunderbird's spam filtering gets them.
postgrey is the package if you're using Postfix on Debian. New sources
are told 'not yet' for - I think - ten minutes. If they try again after
that, they get through. But the logfiles are full of spambots that don't
bother.
I'm very grateful that not everyone does it.
Ian
18 Feb
18 Feb
11:22 a.m.
On Sun, Feb 16, 2014 at 11:45:20PM +0000, Ian wrote:
ed said:
I used greylisting for a while, but I found too many false positives
(for me) with sites that are "legit" but don't work with it. Generally
it seemed to be situations like big sites that would retry from one of a
cluster of MTA boxes.
Do you have any problems? Maybe the world has improved since I last
tried it.
Michael
Alternatively, you could try greylising, 4xx the
sending mail server IP
for thirty minutes on the first mail seen from it, then allow it. Often
this helps as most exploited spam sources don't queue.
Greylisting is my solution. So little gets past it that I don't bother
with spamassassin. Occasionally, a handful come via a spammer who does
follow RFCs, but Thunderbird's spam filtering gets them.
postgrey is the package if you're using Postfix on Debian. New sources
are told 'not yet' for - I think - ten minutes. If they try again after
that, they get through. But the logfiles are full of spambots that don't
bother.
I'm very grateful that not everyone does it. 
11:54 a.m.
Michael Stevens <mstevens(a)etla.org> said, in message
20140218112200.GC783(a)ceres.etla.org:
I used greylisting for a while, but I found too many false positives
(for me) with sites that are "legit" but don't work with it. Generally
it seemed to be situations like big sites that would retry from one
of a cluster of MTA boxes.
We discovered the cluster issue back in 2003 when testing the theory. My
solution was to just use the sender/recipient address as the key,
rather than sender/recipient/IP. I also wired in a pattern match to try
to strip out VERP from addresses so they get a free pass through the
greylisting.
Here's what I wrote back in December 2003, after we'd had
greylisting in place for 3 months:
http://users.aber.ac.uk/auj/spam/greydesc.cgi
We kept the system in place for just shy of 10 years and only got
rid of it when we outsourced mail to Microsoft. It was pretty much
self-maintaining.
Cheers,
Alun.
--
Alun Jones, auj(a)aber.ac.uk, 01970 622494
Gwasanaethau Gwybodaeth / Information Services
Prifysgol Aberystwyth / Aberystwyth University
12:01 p.m.
On 18 Feb 2014, at 11:54, Alun <alun.bitfolk(a)ty-penguin.org.uk> wrote:
Nice - but 42,000 - 25,000 is 17,000 :)
--
Andy Armstrong, Hexten
12:59 p.m.
Andy Armstrong <andy(a)hexten.net> said, in message
FC13BD69-AE18-43CB-8EBD-66E01026BE51(a)hexten.net:
On 18 Feb 2014, at 11:54, Alun
<alun.bitfolk(a)ty-penguin.org.uk> wrote:
Nice - but 42,000 - 25,000 is 17,000 :)
D'Oh!
That's been up for 10 years. Now fixed.
Cheers,
Alun.
--
Alun Jones, auj(a)aber.ac.uk, 01970 622494
Gwasanaethau Gwybodaeth / Information Services
Prifysgol Aberystwyth / Aberystwyth University
12:27 p.m.
Michael said:
I used greylisting for a while, but I found too many
false positives
(for me) with sites that are "legit" but don't work with it. Generally
it seemed to be situations like big sites that would retry from one of a
cluster of MTA boxes.
Do you have any problems? Maybe the world has improved since I last
tried it.
Postgrey comes with some whitelisted exceptions for places like Google,
but they aren't the ones who are sending the spam.
There is one source I needed to whitelist myself, but they're the sort
of place that rejects postmaster@ email with 'no such user', sigh.
Ian
17 Feb
17 Feb
12:05 a.m.
Thanks everyone for your suggestions. As at 23:15 it's reached 24,648
rejected spam emails.
On 16/02/2014 15:28, Andy Bennett wrote:
Just firewall everything for 12 hours. If that's
not enough to encourage
the spammers to give up then you can probably extend it a little more
without having any remote mailservers bounce messages.
During this time, legitimate mail should queue on the sending host and
be retried for anywhere between 24 and 72 hours.
Unfortunately this wouldn't be satisfactory for my clients and, as this
is the second time in 3 weeks that it's been hit by this level of
inbound spam (it's not relay attempts - my server gives that short
shrift), doing that once a month would be both a pain and cause me to
get phone calls. As long as my clients get their messages in a
reasonably timely manner they are generally happy (mail does appear to
be getting through despite my home mail server's issues connecting).
On 16/02/2014 20:52, ed wrote:
Not for SpamAssassin, but have you thought about using
one of the
RBLs? Then you'd block potential junk before you start spending CPU
time on bayes filtering.
Currently I only use RBLs as part of the Spamassassin checks and
scoring. I'm worried about applying stricter RBL checks due to various
issues such as the lag or difficulty in removing entries and the poor
configuration of some of my clients' regular contact's mail systems and
lack of understanding on both sides when mail is rejected.
Alternatively, you could try greylising, 4xx the
sending mail server
IP for thirty minutes on the first mail seen from it, then allow it.
Often this helps as most exploited spam sources don't queue.
(Thanks to Ian for your reply on this too)
I will have a look at greylisting, but I recall from when lug.org.uk
implemented it that there was significant impact and delay with emails
coming through and again this will lead to issues with clients calling
me about emails that they were expecting.
On 16/02/2014 21:53, Keith Williams wrote:
I think the only answer is a good multilayered
approach. Use a couple
of good RBLs.
Ed, Keith (and anyone else) - what RBLs do you consider "good" (taking
into account my previously mentioned concerns)?
Then make sure you are doing all the checks on headers
etc.
I've got several checks, but am always open to additional suggestions.
Then into spamassassin. The next step is to use
fail2ban, so that any
particular IP can only be used by them a couple of times before being
blocked at the firewall. This has limited usefulness tbh, because they
are not using their own machines. What I have done is to research
addresses and found that there are certain ISPs that keep appearing in
spam but not ham. I then log and block them.
I have Fail2ban installed, but I don't have it checking Exim logs. I've
not found a config to do that (my regex foo is not strong), but I do
block IPs that are regular offenders within my IPTables , however as you
note, spammers use many different compromised IPs so that is of limited
value. I've blocked one or two ranges (e.g. Proxad's IPs), but again as
my initial point, banning whole IP ranges could impact on some of my
clients getting legitimate emails.
An interesting thing I have just found from analysing todays logs is
that almost all are being sent to email addresses (mostly rubbish names,
e.g. message IDs) at a single client's domain name. Is there a quick
way in Exim to apply additional rules just to one domain (such as
greylisting or strict application of RBLs)?
Thanks
Gavin
7:46 a.m.
I use SpamCop and SpamHaus RBLs
I am using Postfix so am not 100% about Exim, but I use a range of checks
and reject mail from non existent domains and unauthorised pipelining.
Possibly more but sitting here eating breakfast I can't remember LOL. As
for fail2ban look here
http://www.zaphinath.com/custom-filter-for-exim-through-fail2ban/
On 17 February 2014 00:05, Gavin Westwood <bitfolk-lists(a)gavinwestwood.me.uk
wrote:
Thanks everyone for your suggestions. As at 23:15
it's reached 24,648
rejected spam emails.
On 16/02/2014 15:28, Andy Bennett wrote:
--
Keith Williams
Keith's Place www.keiths-place.co.uk
Tailor Made English www.tmenglish.org
West Norfolk RSPCA www.westnorfolkrspca.org.uk
Just firewall everything for 12 hours. If
that's not enough to encourage
the spammers to give up then you can probably extend it a little more
without having any remote mailservers bounce messages.
During this time, legitimate mail should queue on the sending host and
be retried for anywhere between 24 and 72 hours.
Unfortunately this wouldn't be satisfactory for my clients and, as this
is the second time in 3 weeks that it's been hit by this level of
inbound spam (it's not relay attempts - my server gives that short
shrift), doing that once a month would be both a pain and cause me to
get phone calls. As long as my clients get their messages in a
reasonably timely manner they are generally happy (mail does appear to
be getting through despite my home mail server's issues connecting).
On 16/02/2014 20:52, ed wrote:
Not for SpamAssassin, but have you thought about
using one of the
RBLs? Then you'd block potential junk before you start spending CPU
time on bayes filtering.
Currently I only use RBLs as part of the Spamassassin checks and
scoring. I'm worried about applying stricter RBL checks due to various
issues such as the lag or difficulty in removing entries and the poor
configuration of some of my clients' regular contact's mail systems and
lack of understanding on both sides when mail is rejected.
Alternatively, you could try greylising, 4xx the
sending mail server
IP for thirty minutes on the first mail seen from it, then allow it.
Often this helps as most exploited spam sources don't queue.
(Thanks to Ian for your reply on this too)
I will have a look at greylisting, but I recall from when lug.org.uk
implemented it that there was significant impact and delay with emails
coming through and again this will lead to issues with clients calling
me about emails that they were expecting.
On 16/02/2014 21:53, Keith Williams wrote:
I think the only answer is a good multilayered
approach. Use a couple
of good RBLs.
Ed, Keith (and anyone else) - what RBLs do you consider "good" (taking
into account my previously mentioned concerns)?
Then make sure you are doing all the checks on
headers etc.
I've got several checks, but am always open to additional suggestions.
Then into spamassassin. The next step is to use
fail2ban, so that any
particular IP can only be used by them a couple of times before being
blocked at the firewall. This has limited usefulness tbh, because they
are not using their own machines. What I have done is to research
addresses and found that there are certain ISPs that keep appearing in
spam but not ham. I then log and block them.
I have Fail2ban installed, but I don't have it checking Exim logs. I've
not found a config to do that (my regex foo is not strong), but I do
block IPs that are regular offenders within my IPTables , however as you
note, spammers use many different compromised IPs so that is of limited
value. I've blocked one or two ranges (e.g. Proxad's IPs), but again as
my initial point, banning whole IP ranges could impact on some of my
clients getting legitimate emails.
An interesting thing I have just found from analysing todays logs is
that almost all are being sent to email addresses (mostly rubbish names,
e.g. message IDs) at a single client's domain name. Is there a quick
way in Exim to apply additional rules just to one domain (such as
greylisting or strict application of RBLs)?
Thanks
Gavin
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
9:14 a.m.
Hi all,
I'd strongly recommend greylisting. From experience I can say that
most concerns about delays are easily dealt with. I wrote a greylisting
system for exim back in 2003. We used it to filter all e-mail to
Aberystwyth University from 2003 until the powers-that-be decided to
outsource to Microsoft last year. It caused almost no problems over
those 10 years.
You can get around most delivery delay issues by having a whitelist of legit
hosts that send lots of mail to your machine and a whitelist of
sender/recipient pairs - you make outgoing mail create the whitelist entry
and you can then accept inbound mail without delaying it.
My greylisting implementation managed both the host and
sender/recipient whitelists automatically. It used MySQL as the backend
because we were running a cluster of several mail servers and I wanted
the greylist to be common to all. It should be quite easy to change it
to use SQLite, for example.
Here's a link: http://users.aber.ac.uk/auj/spam/
Spamassassin should really be your last resort when trying to deal with high
throughput. It can take several seconds for a message to pass through
the filters, so knocking off the worst cases nice and early is
worthwhile.
Here's a bit of sneaky stuff to put in your "acl_smtp_connect" ACL.
# ACL for initial connects.
# Let's try and deter them here.
check_connect:
# Internal addresses.
accept hosts = +relay_hosts
# Addresses in one of these DNSBLs get delayed for 60 seconds.
accept dnslists = sbl.spamhaus.org
logwrite = Delayed $sender_host_address - dnsbl $dnslist_domain
delay = 60s
# Addresses without a reverse DNS get delayed for 10 seconds.
accept condition = ${if def:sender_host_name {no}{yes}}
logwrite = Delayed $sender_host_address - missing reverse DNS
delay = 10s
# Everyone else gets 2 seconds to screw them up if they're
# trying to "pump and dump"
accept delay = 2s
Basically, every inbound connection gets delayed for 2 seconds. If they're
in sbl.spamhaus.org the connection gets delayed for 60 extra seconds. If
they have a missing reverse DNS they get 10 seconds added. This is enough
to cause a lot of spamware to give up on you, and the RFCs suggest that
sending software should be willing to wait up to 5 minutes.
The unconditional 2 seconds delay breaks spamware that tries to use
pipelined commands.
Note that nothing in the above ACL causes rejection. It just gives broken
spamware a chance to fail.
I also have an "acl_smtp_helo" which blocks people who HELO as my server
(my server being ty-penguin.org.org or mail.ty-penguin.org.uk) or who
HELO with an invalid value.
check_helo:
# MSA or SMTPS gets a free pass.
accept condition = ${if or {{eq {$interface_port}{587}}{eq {$interface_port}{465}}}}
drop condition = ${if or {\
{eq {$sender_helo_name}{[$interface_address]}}\
{eq {$sender_helo_name}{$interface_address}}\
{eq {$sender_helo_name}{ty-penguin.org.uk}}\
{eq {$sender_helo_name}{mail.ty-penguin.org.uk}}\
}{yes}{no}}
message = You're not me! Are you a spammer?
delay = 3s
drop condition = ${if or {\
{eq {$sender_helo_name}{localhost}}\
{eq {$sender_helo_name}{127.0.0.1}}\
{eq {$sender_helo_name}{[127.0.0.1]}}\
{match {$sender_helo_name}{\N^\.\N}}\
{match {$sender_helo_name}{\N\.\.\N}}\
{match {$sender_helo_name}{\N^[^\.]+$\N}}\
}{yes}{no}}
message = Invalid HELO address
delay = 3s
accept
I think it's perfectly fair to drop stuff that has a clearly invalid HELO. I
also give them a 3 second delay to slow them down a bit. In my experience,
lots of spamware sends dodgy HELO lines in the hope of fooling you into
thinking the mail is local.
Cheers,
Alun.
10:30 a.m.
On 17/02/2014 09:14, Alun wrote:
I'd strongly recommend greylisting. From
experience I can say that
most concerns about delays are easily dealt with. I wrote a greylisting
system for exim back in 2003. We used it to filter all e-mail to
Aberystwyth University from 2003 until the powers-that-be decided to
outsource to Microsoft last year. It caused almost no problems over
those 10 years.
I can vouch for Alun's greylisting scripts :) I used them for a couple
of years back when I was handling our mail with Exim.
Mike
10:35 a.m.
Just spotted this:
An interesting thing I have just found from analysing
todays logs is
that almost all are being sent to email addresses (mostly rubbish names,
e.g. message IDs) at a single client's domain name.
Does this mean you're putting messages through spamassassin regardless of
whether you'd be able to deliver them in the end? This is probably your
biggest problem. There's no point in scanning stuff you're going to
bounce anyway.
You probably need something like the following in your acl_smtp_rcpt ACL:
deny domains = +local_domains
!verify = recipient
Cheers,
Alun.
--
Alun Jones, auj(a)aber.ac.uk, 01970 622494
Gwasanaethau Gwybodaeth / Information Services
Prifysgol Aberystwyth / Aberystwyth University
8:57 a.m.
Hi Gavin,
On Mon, Feb 17, 2014 at 1:05 AM, Gavin Westwood
<bitfolk-lists(a)gavinwestwood.me.uk> wrote:
On 16/02/2014 21:53, Keith Williams wrote:
I recommend the Spamhaus ZEN[*].
Best regards,
Daniel
[*] http://www.spamhaus.org/zen/
I think the only answer is a good multilayered
approach. Use a couple
of good RBLs.
Ed, Keith (and anyone else) - what RBLs do you consider "good" (taking
into account my previously mentioned concerns)?
10:03 a.m.
Gavin said:
I will have a look at greylisting, but I recall from
when lug.org.uk
implemented it that there was significant impact and delay with emails
coming through and again this will lead to issues with clients calling
me about emails that they were expecting.
Email is not a real-time service :)
With this implementation, the only one from any address that is delayed
for a few minutes is the first one. After that, they're in the accept
list and go straight through.
An interesting thing I have just found from analysing
todays logs is
that almost all are being sent to email addresses (mostly rubbish names,
e.g. message IDs) at a single client's domain name. Is there a quick
way in Exim to apply additional rules just to one domain (such as
greylisting or strict application of RBLs)?
How large is the number of legit email addresses?
Ian
19 Feb
19 Feb
7:22 p.m.
Well, I haven't followed this thread much at all, but if you haven't already, you
may want to separate your clients onto two distinct servers: one whitelist, and one dirty
list. This will have the effect of easing your worry, and may allow you to isolate the
reason for the disruption. If that reason is not to your standard user agreement, you
might be able to persuade your dirty list users to curtail their questionable practices.
Le Lundi 17 février 2014 11h03, Ian <ian(a)lovingboth.com> a écrit :
Gavin said:
I will have a look at greylisting, but I recall from
when lug.org.uk
implemented it that there was significant impact and delay with emails
coming through and again this will lead to issues with clients calling
me about emails that they were expecting.
Email is not a real-time service :)
With this implementation, the only one from any address that is delayed
for a few minutes is the first one. After that, they're in the accept
list and go straight through.
An interesting thing I have just found from analysing
todays logs is
that almost all are being sent to email addresses (mostly rubbish names,
e.g. message IDs) at a single client's domain name. Is there a quick
way in Exim to apply additional rules just to one domain (such as
greylisting or strict application of RBLs)?
How large is the number of legit email addresses?
Ian
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
17 Feb
17 Feb
11:06 a.m.
On Mon, Feb 17, 2014 at 12:05:53AM +0000, Gavin Westwood wrote:
I will have a look at greylisting, but I recall from
when lug.org.uk
implemented it that there was significant impact and delay with emails
coming through and again this will lead to issues with clients calling
me about emails that they were expecting.
The delay depends on the sending server I believe, and supposedly
varies, I've always found it to be about 15 minutes.
Certainly my experience is that greylisting is incredible - it loses
about 85% of our incoming mail with no errors. For us that is hundreds
of thousands of emails consigned to oblivion every month.
That said, there are some disadvantages - there have been a couple of
occasions when that 15 minute delay has caused problems, it isn't RFC
compliant and I know some people consider grey listing to be evil.
I would not be without it.
I have Fail2ban installed, but I don't have it
checking Exim logs. I've
not found a config to do that (my regex foo is not strong), but I do
You shouldn't need regex surely, on systems where I have exim installed
I just have the following in my /etc/fail2ban/jail.local file:
[exim]
enabled = true
port = smtp,ssmtp
filter = exim
maxretry = 3
[exim-relay]
enabled = true
port = smtp,ssmtp
filter = exim-relay
maxretry = 1
And then restart fail2ban.
One thing I would say about fail2ban is to test that it is working. To
some degree monitoring logs will achieve this, but I have found it to be
fairly important to physically test.
One specific problem, which may be resolved now, is that I found that I
needed the following in the [DEFAULT] section of jail.local (or
jail.conf), without this fail2ban ironically failed to ban.
backend = polling
An idle google came up with the following iptables method for
restricting connections:
You can do limit SMTP session limit as well using
IPTABLES.... Add
below command in your IPTBALES /etc/sysconf/iptables
-A INPUT -i eth0 -p tcp -m tcp --dport 25 -m limit --limit 20/min -j
ACCEPT
This will limit users to 20 sessions per min...
No idea of its efficacy, but it seems reasonable.
Chris.
--
Chris Roberts
11:53 a.m.
Christopher Roberts <cjr(a)tridentgarages.co.uk> said, in message
20140217110647.GE12544(a)bootpolish.net:
That said, there are some disadvantages - there have been a couple of
occasions when that 15 minute delay has caused problems, it isn't RFC
compliant and I know some people consider grey listing to be evil.
AFAIK greylisting *is* RFC compliant. It's leveraging the standards
in a compliant manner to the disadvantage of non-compliant software
(i.e. spamware). RFC2821 says the following:
The sender MUST delay retrying a particular
destination after one
attempt has failed. In general, the retry interval SHOULD be at
least 30 minutes; however, more sophisticated and variable strategies
will be beneficial when the SMTP client can determine the reason for
non-delivery.
Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. The
parameters to the retry algorithm MUST be configurable.
So a 15 minute temporary deferral shouldn't cause any problem with any RFC
compliant sender.
When we used it in Aber, we stuck with a full hour long deferral on the
basis this might give spammers time to end up in RBLs etc. Complaints
were rare, but there's nothing stopping people using a 1 minute deferral
period to reduce the delay (modulo the remote end's retry policy).
Entertainingly, I see there's now an RFC describing greylisting:
http://tools.ietf.org/search/rfc6647
The biggest justifiable evilness of greylisting is in expecting other
sites to do more work in getting mail to you. To block that vast amount
of spam, you're forcing legitimate sites to expend effort queuing
and retrying messages. Personally, I hold very little truck with
that argument. First off, the whitelisting that is part of the
greylisting process means that the vast majority of legit mail
doesn't end up being deferred. Secondly the argument works both
ways. My mail server has to do extra work to deliver to a site
implementing greylisting. Both my server and the remote server
benefit from the arrangement. I'd imagine the overheads are
negligible for all but the largest senders on the planet and,
given they're in it for the cash, having them bear a small
amount of extra hardware and network cost isn't something
that's going to make me cry.
Cheers,
Alun.
--
Alun Jones, auj(a)aber.ac.uk, 01970 622494
Gwasanaethau Gwybodaeth / Information Services
Prifysgol Aberystwyth / Aberystwyth University
8:59 p.m.
Alun said:
AFAIK greylisting *is* RFC compliant. It's
leveraging the standards
in a compliant manner to the disadvantage of non-compliant software
(i.e. spamware). RFC2821 says the following:
Beat me to it :)
An earlier email RFC said it should work, i.e. the sender "SHOULD"
resend, and now it 'must' to be RFC-compliant.
The biggest justifiable evilness of greylisting is in
expecting other
sites to do more work in getting mail to you.
I think it's hoping that not everyone implements it and gets the
benefits! If everyone greylisted, it would stop working as the spambots
would have to be made compliant.
Fortunately, they don't, so they're not, so it works.
Ian
10:15 p.m.
Hi,
I think it's hoping that not everyone implements
it and gets the
benefits! If everyone greylisted, it would stop working as the spambots
would have to be made compliant.
Fortunately, they don't, so they're not, so it works.
Greylisting is more of an economic thing than an arms-race thing.
Regards,
@ndy
--
andyjpb(a)ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
18 Feb
18 Feb
12:33 a.m.
Thanks everyone for your help. I'll definitely look at those
greylisting rules and that fail2ban link for the exim rules (they don't
seem to be part of the default packaged version in Debian Wheezy).
Sorry for the short reply as only just got home. I'll reply to specific
emails tomorrow.
Thanks
Gavin
3719
days inactive
3722
days old
22 comments
13 participants
participants (13)
-
Alun -
Alun -
Andy Armstrong -
Andy Bennett -
Christopher Roberts -
Daniel Néri -
ed -
Gavin Westwood -
Ian -
Keith Williams -
Max B -
Michael Stevens -
Mike Zanker