On Wed, Aug 05, 2020 at 10:41:13AM -0300, SysAdmin EM wrote:
> My problem is that I cannot deliver the mail because the greylist does not
> allow it and in some cases I also receive the same error in the other MXs.
Receiving the same greylist error from the second MX has the positive
effect of "priming" the greylist timer on the second MX when the two
don't share a greylist cache.
Since immediate fallback SMTP connections to a second MX to handle
temp-failed recipients is NOT(!) a separate delivery attempt, it is an
integral part of the original single delivery attempt. No timers or
other tweaks will cause that connection to be delayed, and delaying is
NOT a good idea. What "actual problem" are you trying to "sove"?
After an immediate fallback to a second MX the message is now awaiting
retransmission on two MX hosts. That's a feature, not a bug. Why are
you trying to avoid this?
> Jul 31 09:30:08 smarthost03-ded postfix/smtp[22475]: A88B418003D5B:
> to=<ism...@ilaviola.com.ar>, relay=mx7.webfaction.com[185.20.49.162]:25,
> delay=969, delays=962/0.01/6.8/0.34, dsn=4.2.0, status=deferred (host
> mx7.webfaction.com[185.20.49.162] said: 450 4.2.0
> <ism...@ilaviola.com.ar>: Recipient address rejected: Greylisted for 300
> seconds (in reply to RCPT TO command))
> Jul 31 09:31:04 smarthost03-ded postfix/smtp[22767]: A88B418003D5B: host
> mx9.webfaction.com[185.20.49.164] said: 450 4.2.0
> <ism...@ilaviola.com.ar>: Recipient address rejected: Greylisted for 300
> seconds (in reply to RCPT TO command)
This is rather *different* from your first example. This case was NOT
an immediate fallback to a second MX. The smtp(8) process id is
different for the two log entries, and the first message logged the
*final* (dsn=4.2.0, deferred) status for its delivery attempt:
> Jul 31 09:30:08 smarthost03-ded postfix/smtp[22475]: A88B418003D5B:
> to=<ism...@ilaviola.com.ar>, relay=mx7.webfaction.com[185.20.49.162]:25,
> delay=969, delays=962/0.01/6.8/0.34, dsn=4.2.0, status=deferred (host
And at ~56 seconds the two are much too far apart to be plausibly part
of the same delivery. Perhaps at the time (and maybe still) you had a
minimal backoff time that is much too short? The defaults are:
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
Did you (at least on Jul 31) have a much shorter minimal_backoff_time?
Is your mail queue on NFS? If so, is the NFS server's clock correctly
synced with the Postfix server? Is your queue on some funky file system
that does not correctly record file modification times?
> I am use PowerMTA and depending on the message I receive, I can perform an
> action such as hold the queue waiting for a certain time and not in postfix.
This makes no sense. You're showing Postfix logging, so Postfix has the
message.
> I understand that postfix retries on all MXs in the domain, can I configure
> the retry time towards the second MX? I did not find it in the
> documentation http://www.postfix.org/qmgr.8.html
You're very confused, and not paying attention to the details in the log
messages. Log messages with "dsn=X.Y.Z, status=..." are the final
status (for that recipient) when all candidate MX hosts have been
exhausted. Earlier log entries with the same process id and queue id
that show a "4XX" tempfail respsonse, but no "dsn=X.Y.Z, status=..."
are not the final result, and a fallback MX will be tried immediately.
> Can i automatically send the queue into hold when i get a greylist error?
Why on earth would you want to do that?
On Wed, Aug 05, 2020 at 10:57:14AM -0300, SysAdmin EM wrote:
> Is it possible to change the retransmission time to the second max?
No, because immediate fallback to a second attempt during a given
delivery attempt IS NOT a retry of a deferred message. And because you
don't want to do this, even if you think you want to do it, barring an
extraordinary reason you've still failed to explain.
On Wed, Aug 05, 2020 at 11:11:45AM -0300, SysAdmin EM wrote:
> I think I have found what I need, I must increase the value of the
> parameter "transport_retry_time".
No you have not, and you SHOULD NOT randomly change settings you do
not understand. You should undo that change.
> ### transport_retry_time (default: 60s)
> The time between attempts by the Postfix queue manager to contact a
> malfunctioning message delivery transport.
Changing this will in no way address your purported issue, and can only
degrade the performance of your Postfix system.
> I will increase the value and I will see how it behaves thanks to everyone
> for helping me, take good care
I am trying to tell you are solving the wrong problem. You're still
down in the weeds explaining difficulties implementing your solution
to the wrong problem, rather than explaining the *ultimate* reason
you're doing anything at all.
Given your second example, perhaps you have an unreasonably short
minimal_backoff_time, or your filesystem reports bogus modification
times.
--
Viktor.
