1 Topic by rafaelr

  • rafaelr
  • Member
  • Offline
  • Registered: 2015-03-26
  • Posts: 26

Topic: A note on the newest 0.9.3 release

==== Required information ====
- iRedMail version (check /etc/iredmail-release):
- Linux/BSD distribution name and version:
- Store mail accounts in which backend (LDAP/MySQL/PGSQL):
- Web server (Apache or Nginx):
- Manage mail accounts with iRedAdmin-Pro?
- Related log if you're reporting an issue:
====

Hello Zhang and all iRedMail followers and supporters.

I've gone through the upgrade documentation and things look promising; great job! As such, I've planned my upgrade for this weekend and I look forward to it smile

Zhang, I noticed in the docs section: "[OPTIONAL] Fail2ban: Update regular expression to catch postscreen log" ... and I will be very cautious to commit this change:

reject: RCPT from (.*)\[<HOST>\]:([0-9]{4,5}:)? 550

In my opinion, if I'm understanding it right, this will cause some problems in a very short run. For example, my logs do show spammers using gmail (Google servers) and others providers trying to deliver emails to non-existent accounts which causes a 550 rejection. Also, rejections from DNSBL services are 550s.

There is always the concern about performance also. If a user is running a small KVM or OpenVZ VPS, the thousands of iptables records created by this fail2ban catch rule can really put the server on its knees depending on the amount of connections (transactions) that the mailer does.

Maybe I'm missing the point here but I think this catch rule will cause more harm than the intended good. I think postfix and DNSBL rejections at this point does better. Maybe other admins can corroborate on this.

All the best!

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 31,165

Re: A note on the newest 0.9.3 release

rafaelr wrote:

reject: RCPT from (.*)\[<HOST>\]:([0-9]{4,5}:)? 550
In my opinion, if I'm understanding it right, this will cause some problems in a very short run. For example, my logs do show spammers using gmail (Google servers) and others providers trying to deliver emails to non-existent accounts which causes a 550 rejection. Also, rejections from DNSBL services are 550s.

There's a difference between normal rejection (like 'user not exist') and postscreen: log of postscreen rejection will have a port number right after HOST. for example:

Dec 15 21:24:06 mail postfix/postscreen[10289]: NOQUEUE: reject: RCPT from [87.242.73.242]:60765: 550 5.7.1 Service unavailabed using zen.spamhaus.org; from=<alexander@bibik.ru>, to=<test@mail.iredmail.org>, proto=ESMTP, helo=<localhost.localdomain>

And here's normal rejection:

Dec 14 20:36:10 mail postfix/smtpd[23843]: NOQUEUE: reject: RCPT from hosting.jamii.co.ke[41.57.96.54]: 550 5.1.1 <boss@iredmail.org>: Recipient address rejected: User unknown in virtual mailbox table; from=<info@royalcityhotel.co.ke> to=<boss@iredmail.org> proto=ESMTP helo=<hosting.jamii.co.ke>

So, the new fail2ban regular expression rule just catches postscreen rejection.

Besides, we run below rules (/etc/fail2ban/filter.d/postfix.iredmail.conf) for years, and it works fine:

[Definition]
failregex = \[<HOST>\]: SASL (PLAIN|LOGIN) authentication failed
            lost connection after (AUTH|UNKNOWN|EHLO) from (.*)\[<HOST>\]
            reject: RCPT from (.*)\[<HOST>\]: 550 5.1.1
            reject: RCPT from (.*)\[<HOST>\]: 450 4.7.1
            reject: RCPT from (.*)\[<HOST>\]: 554 5.7.1
            reject: RCPT from (.*)\[<HOST>\]: 504 5.5.2 (.*) Helo command rejected: need fully-qualified hostname
            reject: RCPT from (.*)\[<HOST>\]:\d+: 550
            warning: Illegal address syntax from (.*)\[<HOST>\] in RCPT command
ignoreregex =

3 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 31,165

Re: A note on the newest 0.9.3 release

rafaelr wrote:

There is always the concern about performance also. If a user is running a small KVM or OpenVZ VPS, the thousands of iptables records created by this fail2ban catch rule can really put the server on its knees depending on the amount of connections (transactions) that the mailer does.

More IP blocks in iptables just takes some memory, but a mail delivery attempt will query SQL/LDAP and maybe spamassassin + clamav (if it enters mail queue), i don't see there's any performance concern.

4 Reply by extremeshok (edited by extremeshok 2015-12-16 09:34:19)

  • extremeshok
  • Member
  • Offline
  • From: https://eXtremeSHOK.com
  • Registered: 2014-03-19
  • Posts: 25

Re: A note on the newest 0.9.3 release

Zhang asked me to reply.

We have used that rule in production for more than a year. Our mail-servers send and receive millions of emails in a month.

If you monitor the maillog in realtime (tail -f /var/log/maillog) , you will notice spam sending servers will constantly connect and reconnect, evern after receiving a 550. The only way to stop them is to ban their ip.

The constant attempted delivery of spam uses up connections and cpu cycles to continuously query the dnsbl and bounce the sender.

Eventually your dnsbl providers will ban you for too many lookups, and the spam goes through. If you use dns caching, you still waste the cpu cycles.

Status for the jail:
|- Filter
|  |- Currently failed: 1155
|  |- Total failed:     23571
|  `- File list:        /var/log/maillog
`- Actions
   |- Currently banned: 109
   |- Total banned:     1921

So even with 23 000 failed IP's, only the true spam servers will be blocked and added to your ip tables, in this case 109 ips are banned.

BTW, iptables will always use far less resources than a connection to postfix on port 25 and then performing the various validations and lookups.

extremeshok's Website