• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Incoming mail delay (huge)

VicenteS

New Pleskian
Hi.

I'm having problem with some incoming mails because the have a very very huge delay (even some hours).

My configuration is:

- Standard email server from plesk (i think is qmail)
- SPF
- Spamassasin
- MagicSpam (module)

Some mails get delays and others not, for example dropbox mails have about 10 min. of delay after server get the mail (so is not carriers delay)

My log file is:

Feb 7 18:50:19 magicspam-plesk[15095]: HAM: mua=0,ip=[75.126.110.122:mailman-2.dropboxmail.com],helo=<mailman-2.dropboxmail.com>,from=<[email protected]>,rcpt=<CENSORED>
Feb 7 18:50:19 qmail-queue-handlers[15096]: Handlers Filter before-queue for qmail started ...
Feb 7 18:50:19 qmail-queue-handlers[15096]: [email protected]
Feb 7 18:50:19 qmail-queue-handlers[15096]: to=CENSORED
Feb 7 18:50:19 greylisting filter[15097]: Starting greylisting filter...
Feb 7 18:50:19 qmail-queue-handlers[15096]: call_handlers: stop call handlers from dir '/opt/psa/handlers/before-queue/global'

Some pause.

Server CPU is 0%, RAM is not full (about 20%)

Then:

Feb 7 18:58:14 magicspam-plesk[15949]: HAM: mua=0,ip=[75.126.110.122:mailman-2.dropboxmail.com],helo=<mailman-2.dropboxmail.com>,from=<[email protected]>,rcpt=<$
Feb 7 18:58:14 qmail-queue-handlers[15950]: Handlers Filter before-queue for qmail started ...
Feb 7 18:58:15 qmail-queue-handlers[15950]: [email protected]
Feb 7 18:58:15 qmail-queue-handlers[15950]: to=CENSORED
Feb 7 18:58:15 reylisting filter[15951]: Starting greylisting filter...
Feb 7 18:58:15 qmail: 1297101495.267589 new msg 49774593
Feb 7 18:58:15 qmail: 1297101495.267613 info msg 49774593: bytes 4754 from <[email protected]> qp 15954 uid 2020
Feb 7 18:58:15 qmail: 1297101495.283941 starting delivery 71: msg 49774593 to local 19-CENSORED
Feb 7 18:58:15 qmail: 1297101495.283960 status: local 1/10 remote 0/20
Feb 7 18:58:15 qmail-local-handlers[15955]: Handlers Filter before-local for qmail started ...
Feb 7 18:58:15 qmail-local-handlers[15955]: [email protected]
Feb 7 18:58:15 qmail-local-handlers[15955]: to=CENSORED
Feb 7 18:58:15 qmail-local-handlers[15955]: mailbox: /var/qmail/mailnames/CENSORED

I have try to disable anti-spams and other features but i cant find the problem

Do you know what the problem is?

Thanks.
 
Hi,

maybe it's the greylisting which is enabled. With greylisting it can't take up a few hours until a mail is delivered (it depends on the senders server configuration). We have also Magicspam running on our servers and we have disabled greylisting because of the delays.

Try to disable greylisting and see if there is a difference.

Maybe I could help you

With best regards
 
hi
how to disable greylisting and see if there is a difference.
 
Turn off Greylisting in

Settings > Mail

Honestly, I love the idea behind Greylisting. Do you know how it works?

http://en.wikipedia.org/wiki/Greylisting

Based on reading that, you'll understand that the first time an e-mail from a server is received, it is rejected as if your server could not be reached. The theory is that if the mail server is a legitimate mail server, it'll attempt to redeliver the mail. When your server sees that, it lets mail in the second time -- thus the delay is based on how long the other server waits to retry. After a successful mail goes through, it whitelists the other server (for a while at least).

Where Greylisting totally fails is when someone sending legitimate mail to you is doing so with either an improperly configured server, or a mass mailing that doesn't redeliver -- for something that you or your clients MIGHT want.

So - my 2c on Greylisting is that it's a terrible idea that should always remain experimental - not suggested for production servers - and an sadly awesome idea that seems to get rid of 90%+ of spam, lower cpu processes that would be used by spamassassin, and unfortunately, not always work with everyone else's servers.
 
Back
Top