Postgrey causing 15+ minute delays for legitimate incoming emails – best way to handle this?

Help with Setup/Upgrade
1

Hi,

I’m running Mail-in-a-Box v74 and I’ve recently noticed that some legitimate incoming emails can take 10–15 minutes (or sometimes longer) to arrive.

After checking /var/log/mail.log , it appears that Postgrey is causing the delay.

My current Postgrey configuration is:

--inet=127.0.0.1:10023 --delay=180 --dbdir=/home/user-data/mail/postgrey/db

So the configured greylisting delay is only 180 seconds, but the actual delay can be much longer because the sending SMTP server decides when to retry.

For example, I have legitimate emails from Accor that are initially rejected:

postgrey: action=greylist, reason=new
postfix/smtpd: NOQUEUE: reject: RCPT ...
450 4.2.0 Recipient address rejected: Greylisted

One example:

13:04:48  First delivery attempt → greylisted
13:19:50  Sender retries → accepted
13:19:55  Message delivered to my mailbox

So this legitimate email was delayed by about 15 minutes.

I have another current example from an @accor.com sender relayed through Trend Micro:

15:58:44 connect from repost01.tmes.trendmicro.eu
postgrey: action=greylist, reason=new
sender=HA4A5@accor.com
recipient=<my address>

Postfix responded:

450 4.2.0 Recipient address rejected: Greylisted

and the remote server had still not retried when I checked later.

Other senders behave differently. For example, an Apple mail was greylisted but Apple retried about 5 minutes later and the message was then delivered normally.

Once Postgrey accepts a message, everything seems fine on my server: spam filtering and LMTP/Dovecot delivery generally take only a few seconds. The Postfix queue is also empty.

So my questions are:

  1. Is greylisting still considered useful/recommended with current Mail-in-a-Box versions?
  2. Is there a supported way in Mail-in-a-Box to disable Postgrey/greylisting?
  3. Would disabling it have a significant impact on spam with the other anti-spam mechanisms used by MIAB?
  4. Alternatively, is there a recommended way to whitelist major/legitimate mail infrastructures without maintaining a large manual whitelist?
  5. If I modify the Postgrey/Postfix configuration, what is the recommended way to make the change persistent across Mail-in-a-Box updates?

I understand the purpose of greylisting, but waiting 15+ minutes for things like login codes, booking confirmations, password-reset emails, etc. can be quite inconvenient.

I’d be interested to know how other Mail-in-a-Box users handle this and whether disabling greylisting is considered reasonable nowadays.

Thanks!

2
  1. You can run a grep on the sender you suspect the recipient domain belongs to (Canonical/Ubuntu in the example below), although this is not always obvious.

The problem is with mail senders such as Mailgun or Mailjet, which are email-sending services paid for by other companies to send emails from multiple addresses. Allowing the entire “mailjet” domain, for example, would authorize all emails from companies using their services.

Example :
grep postgrey /var/log/mail.log | grep -iE “ubuntu|canonical” | tail -5
Sep 24 16:01:48 box postgrey[468447]: action=greylist, reason=new, client_name=smtp-relay-services-0.canonical.com, client_address=185.125.188.250/32, sender=noreply@login.ubuntu.com, recipient=yourmail
Sep 24 16:01:48 box postfix/smtpd[522769]: NOQUEUE: reject: RCPT from smtp-relay-services-0.canonical.com[185.125.188.250]: 450 4.2.0 : Recipient address rejected: Greylisted, see Postgrey Help; from=noreply@login.ubuntu.com to= proto=ESMTP helo=<smtp-relay-services-0.canonical.com>
Sep 24 16:06:36 box postgrey[522831]: action=pass, reason=client whitelist, client_name=smtp-relay-services-1.canonical.com, client_address=185.125.188.251/32, sender=noreply@login.ubuntu.com, recipient=yourmail
Sep 24 16:09:58 box postgrey[522831]: action=pass, reason=client whitelist, client_name=smtp-relay-services-0.canonical.com, client_address=185.125.188.250/32, sender=noreply@login.ubuntu.com, recipient=yourmail

then you can create a /etc/postgrey/whitelist_clients.local file that will persist across updates, instead of modifying /etc/postgrey/whitelist_clients, which will be overwritten each time and add to it :

ubuntu.com
canonical .com

  1. do a systemctl restart postgrey.service
1 Like
3

greylisting is almost useless nowadays, and cause more problems than resolves. Turn it off by allowing all mail without greylisting.

4

is there an option in mailinabox to disable it ? or if I do it manually, I have to disable it at each upgrade ?

5

I had the same frustration with postgrey. It greylists every new sender, server and recipient combination, however legitimate the mail is, so the real delay comes down to how long the sending server waits before retrying. That’s why Apple got through in 5 minutes and Accor/Trend Micro took 15 or more.

For your current box: @bobaxx’s /etc/postgrey/whitelist_clients.local approach is the way to go. Unlike whitelist_clients, that file survives Mail-in-a-Box upgrades. As far as I know, MiaB has no built-in setting to turn greylisting off, so a manual change risks being undone by the next setup run.

Another option, if you’re open to a rebuild: full disclosure, I maintain MeetrMail, a fork of Mail-in-a-Box v76 ported to Ubuntu 24.04 LTS. One of the bigger changes is that postgrey and SpamAssassin are gone, and Rspamd handles both spam filtering and greylisting. That’s directly relevant to your problem:

  • Rspamd only greylists suspicious mail. It scores each message while the sender is still connected, and only greylists messages that land in the “suspicious” score range. Clean mail from reputable senders like Accor, Apple or Canonical, with SPF, DKIM and DMARC passing, is normally accepted on the first attempt, so login codes and booking confirmations don’t sit waiting.
  • Better spam filtering overall: Rspamd adds reputation checks, fuzzy hashing and Bayes learning. It runs as a milter inside Postfix, so there’s no separate greylisting daemon.
  • A newer base than v74: MeetrMail is built on v76 and runs on Ubuntu 24.04, which is supported for much longer than 22.04, with PHP 8.3 and Python 3.12. It installs with one command, and my own box is live, sending and receiving with Gmail and Outlook.

The honest caveats:

  • It needs a fresh server. MeetrMail targets Ubuntu 24.04, so you can’t upgrade your existing v74 box in place. You’d build a new server and move over to it.
  • Moving your mail over is untested. MeetrMail keeps MiaB’s duplicity backups, so in principle you could back up the old box and restore onto the new one. I haven’t tested a migration from upstream MiaB end to end yet, so I can’t promise it works. If you try it, keep the old server running until you’ve confirmed everything came across.
  • Some legitimate mail can still be greylisted. A message that scores in the suspicious range, for example from a bulk sender with a poor reputation or broken DKIM, can still be delayed. It just happens far less often than with postgrey.
  • It’s a fork, not official MiaB. Support comes from me rather than the MiaB project, so please don’t raise MeetrMail issues here.

Details on what changed and why: MeetrMail – Mail-in-a-Box v76 on Ubuntu 24.04 LTS | GGA Designs. The project is at https://meetrmail.net.

Happy to answer questions if you give it a try. And if you’d rather stay on stock MiaB, the whitelist file above is the lowest-effort fix.

Thanks G

1 Like
6

Finally, I have set up
etc/postgrey/whitelist_clients.local
with /.*/ so postghrey let everybody pass

7

I’d be interested so hear how much spam you start seeing, now you’ve disabled greylisting.

I agree greylisting is a pain when I want a registration email, but the rest of the time I see almost zero spam, so on balance it’s working for me.

1 Like
8

I switched off greylisting 2 years ago, and for me (about 15 domains and 1000 mail addresses) it did make almost no difference.

Greylisting works only when spammer trying to send spam as many and as fast as possible, directly to mail servers. Typically from some hacked computer, or from own internet connection. This is not working anymore, because mail servers have become more restrictive, and usually do not accept mails directly from random IP addresses. Up to 5 year ago, greylisting was relatively efficient and very “cheap” way (in computing power sense) to repel spam.

Today (at least in my case), majority of the spam move through various “spamming service providers” (Sendsmaily, Sendpulse, Hugemailer, etc.) or other mail servers, and in this case, greylisting does almost nothing useful. Only delay legitime emails.

1 Like
9

I’ve been thinking about doing this too… and I just did. If I have problems with spam, I’ll report back.

10

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.