1

Topic: Some ideas for greylisting

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 1.3.2
- Deployed with iRedMail Easy or the downloadable installer? downloadable
- Linux/BSD distribution name and version: Ubuntu 20.04
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Nginx
- Manage mail accounts with iRedAdmin-Pro? No
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

Hi!

The greylisting settings seems to be waiting 15 minutes (by default) before accepting a retried delivery.

What happens if GREYLISTING_BLOCK_EXPIRE is changed to 0 and a secondary MX record for domain is added that points to same mail server?

If I'm thinking this right:
1. Email is sent and greylisting blocks it
2. Email is resent immediately to secondary MX (that points to same server as primary MX)
3. As greylisting block expiry is set to 0, server accepts the email
4. User is happy and the email gets delivered without delay

----

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

2

Re: Some ideas for greylisting

Interesting idea, but this completely negates greylisting. Additionally, some spammers will try delivering their spam to an MX with a *higher* priority (i.e., higher number) *first*, so it seems to me your idea wouldn't accomplish anything.


Craig

3

Re: Some ideas for greylisting

It wouldn't matter if spammer tries to deliver to higher priority MX, if both records actually points to same server. In any case the first email would be greylisted anyway.

4

Re: Some ideas for greylisting

- If you set GREYLISTING_BLOCK_EXPIRE=0, then it bypasses at 2nd retry directly, why bother involve a second server? big_smile
- Most servers retry by connecting to the previous server, but big ISPs may try different servers in MX, you cannot expect they all have same behaviour.