Greylisted for 300 seconds and queue_run_delay
Hello, I think I understand that the "queue_run_delay" parameter is used to retry an email. Aug 4 12:19:23 smarthost03-ded postfix/qmgr[11588]: 68E2A18001AF1: from=< ju...@jorgeloinaz.com>, size=131840, nrcpt=1 (queue active) Aug 4 12:19:26 smarthost03-ded postfix/smtp[14720]: 68E2A18001AF1: host mx8.webfaction.com[185.20.49.163] said: 450 4.2.0 : Recipient address rejected: Greylisted for 300 seconds (in reply to RCPT TO command) Aug 4 12:19:29 smarthost03-ded postfix/smtp[14720]: 68E2A18001AF1: to=< ism...@ilaviola.com.ar>, relay=mx7.webfaction.com[185.20.49.162]:25, delay=5 .9, delays=0.5/0/4.2/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2B4C2209E59E8) Aug 4 12:19:29 smarthost03-ded postfix/qmgr[11588]: 68E2A18001AF1: removed The first attempt was at 12:19:23 and then retry 12:19:29, I just wait 3 seconds. I set queue_run_delay in 300s: # postconf | grep queue_run_delay queue_run_delay = 300s Could it be that the retry value is not correctly set? Regards,
Re: Greylisted for 300 seconds and queue_run_delay
On Tue, Aug 04, 2020 at 12:26:03PM -0300, SysAdmin EM wrote: > I think I understand that the "queue_run_delay" parameter is used to retry > an email. > > Aug 4 12:19:26 smarthost03-ded postfix/smtp[14720]: 68E2A18001AF1: > host mx8.webfaction.com[185.20.49.163] said: > 450 4.2.0 : Recipient address rejected: > Greylisted for 300 seconds (in reply to RCPT TO command) > Aug 4 12:19:29 smarthost03-ded postfix/smtp[14720]: 68E2A18001AF1: > to=< ism...@ilaviola.com.ar>, relay=mx7.webfaction.com[185.20.49.162]:25, > delay=5 .9, delays=0.5/0/4.2/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: > queued as 2B4C2209E59E8) > Aug 4 12:19:29 smarthost03-ded postfix/qmgr[11588]: 68E2A18001AF1: removed > > The first attempt was at 12:19:23 and then retry 12:19:29, I just wait 3 > seconds. That was not a "retry" of a deferred message, rather it was the same delivery attempt via a second MX host after the primary temp-failed. ilaviola.com.ar. IN MX 10 mx7.webfaction.com. ilaviola.com.ar. IN MX 10 mx8.webfaction.com. ilaviola.com.ar. IN MX 10 mx9.webfaction.com. > Could it be that the retry value is not correctly set? No, the message never went back into the queue, since it was delivered on the first attempt. The second MX host tried did not enforce greylisting. -- Viktor.
Re: Greylisted for 300 seconds and queue_run_delay
El mar., 4 de ago. de 2020 a la(s) 13:13, Viktor Dukhovni ( postfix-us...@dukhovni.org) escribió: > On Tue, Aug 04, 2020 at 12:26:03PM -0300, SysAdmin EM wrote: > > > I think I understand that the "queue_run_delay" parameter is used to > retry > > an email. > > > > Aug 4 12:19:26 smarthost03-ded postfix/smtp[14720]: 68E2A18001AF1: > > host mx8.webfaction.com[185.20.49.163] said: > > 450 4.2.0 : Recipient address rejected: > > Greylisted for 300 seconds (in reply to RCPT TO command) > > Aug 4 12:19:29 smarthost03-ded postfix/smtp[14720]: 68E2A18001AF1: > > to=< ism...@ilaviola.com.ar>, relay=mx7.webfaction.com > [185.20.49.162]:25, > > delay=5 .9, delays=0.5/0/4.2/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: > > queued as 2B4C2209E59E8) > > Aug 4 12:19:29 smarthost03-ded postfix/qmgr[11588]: 68E2A18001AF1: > removed > > > > The first attempt was at 12:19:23 and then retry 12:19:29, I just wait 3 > > seconds. > > That was not a "retry" of a deferred message, rather it was the same > delivery attempt via a second MX host after the primary temp-failed. > > ilaviola.com.ar. IN MX 10 mx7.webfaction.com. > ilaviola.com.ar. IN MX 10 mx8.webfaction.com. > ilaviola.com.ar. IN MX 10 mx9.webfaction.com. > > > Could it be that the retry value is not correctly set? > > No, the message never went back into the queue, since it was delivered > on the first attempt. The second MX host tried did not enforce > greylisting. > > Any recommendation to avoid retrying the second mx? in some cases when retrying the second mx we also represent the grey list error. > -- > Viktor. >
Re: Greylisted for 300 seconds and queue_run_delay
SysAdmin EM: > El mar., 4 de ago. de 2020 a la(s) 13:13, Viktor Dukhovni ( > postfix-us...@dukhovni.org) escribi?: > > > On Tue, Aug 04, 2020 at 12:26:03PM -0300, SysAdmin EM wrote: > > > > > I think I understand that the "queue_run_delay" parameter is used to > > retry > > > an email. > > > > > > Aug 4 12:19:26 smarthost03-ded postfix/smtp[14720]: 68E2A18001AF1: > > > host mx8.webfaction.com[185.20.49.163] said: > > > 450 4.2.0 : Recipient address rejected: > > > Greylisted for 300 seconds (in reply to RCPT TO command) > > > Aug 4 12:19:29 smarthost03-ded postfix/smtp[14720]: 68E2A18001AF1: > > > to=< ism...@ilaviola.com.ar>, relay=mx7.webfaction.com > > [185.20.49.162]:25, > > > delay=5 .9, delays=0.5/0/4.2/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: > > > queued as 2B4C2209E59E8) > > > Aug 4 12:19:29 smarthost03-ded postfix/qmgr[11588]: 68E2A18001AF1: > > removed > > > > > > The first attempt was at 12:19:23 and then retry 12:19:29, I just wait 3 > > > seconds. > > > > That was not a "retry" of a deferred message, rather it was the same > > delivery attempt via a second MX host after the primary temp-failed. > > > > ilaviola.com.ar. IN MX 10 mx7.webfaction.com. > > ilaviola.com.ar. IN MX 10 mx8.webfaction.com. > > ilaviola.com.ar. IN MX 10 mx9.webfaction.com. > > > > > Could it be that the retry value is not correctly set? > > > > No, the message never went back into the queue, since it was delivered > > on the first attempt. The second MX host tried did not enforce > > greylisting. SysAdmin EM: > Any recommendation to avoid retrying the second mx? in some cases when > retrying the second mx we also represent the grey list error. There is no second MX. Instead, there are three equal-preference MX hosts, and Postfix selects one at random. Wietse
Re: Greylisted for 300 seconds and queue_run_delay
On Tue, Aug 04, 2020 at 02:37:22PM -0300, SysAdmin EM wrote: > > No, the message never went back into the queue, since it was delivered > > on the first attempt. The second MX host tried did not enforce > > greylisting. > > Any recommendation to avoid retrying the second mx? in some cases when > retrying the second mx we also represent the grey list error. Trying a second MX is the right thing to do. - Pattern matching the greylisting response is too fragile. - The various MX hosts may not share their greylisting caches, and you may encounter another greylising delay if you defer and retry. - Probably some other reasons, that I'm too lazy to recall on the spur of the moment. Just let Postfix do its job. -- Viktor.
Re: Greylisted for 300 seconds and queue_run_delay
Thank you very much everyone for the responses. So I think that for this case I have no solution, I will continue investigating thanks El mar., 4 de ago. de 2020 a la(s) 15:03, Viktor Dukhovni ( postfix-us...@dukhovni.org) escribió: > On Tue, Aug 04, 2020 at 02:37:22PM -0300, SysAdmin EM wrote: > > > > No, the message never went back into the queue, since it was delivered > > > on the first attempt. The second MX host tried did not enforce > > > greylisting. > > > > Any recommendation to avoid retrying the second mx? in some cases when > > retrying the second mx we also represent the grey list error. > > Trying a second MX is the right thing to do. > > - Pattern matching the greylisting response is too fragile. > > - The various MX hosts may not share their greylisting caches, > and you may encounter another greylising delay if you defer > and retry. > > - Probably some other reasons, that I'm too lazy to recall on > the spur of the moment. > > Just let Postfix do its job. > > -- > Viktor. >
Re: Greylisted for 300 seconds and queue_run_delay
On Tue, Aug 04, 2020 at 03:19:27PM -0300, SysAdmin EM wrote: > Thank you very much everyone for the responses. > > So I think that for this case I have no solution, I will continue > investigating thanks My take is that rather than "no solution", what you don't have is a "problem". Please consider the strong possibility that everything is working exactly as it should, and it is simply best to not dwell on the logs in question. If you do believe there's actually a problem, i.e. something actually goes wrong as a result of trying to delivery 4XX failures on a second MX host, please explain what it is that does not work the way it should. -- Viktor.
Re: Connection Caching Per-Destination
Wietse Venema: > There is a rough idea of how to enforce strict connection counts > when connection caching is turned on. But it would not help in your > case, where the number of competing domains is 100x the number of > allowed concurrent connections. Under those conditions the feature > would behave as if connection reuse is turned off. An easier fix may be to change the scheduler and suspend round-robin destination selection until a destination is blocked (concurrency limit reached) or drained. This would be less fair in the general case of mixed email flows, but mass email is different enough that people can expect to need some confguration for fastest delivery. Wietse
Re: Greylisted for 300 seconds and queue_run_delay
El mar., 4 de ago. de 2020 a la(s) 15:25, Viktor Dukhovni ( postfix-us...@dukhovni.org) escribió: > On Tue, Aug 04, 2020 at 03:19:27PM -0300, SysAdmin EM wrote: > > Thank you very much everyone for the responses. > > > > So I think that for this case I have no solution, I will continue > > investigating thanks > > My take is that rather than "no solution", what you don't have is a > "problem". Please consider the strong possibility that everything is > working exactly as it should, and it is simply best to not dwell on > the logs in question. > > If you do believe there's actually a problem, i.e. something actually > goes wrong as a result of trying to delivery 4XX failures on a second MX > host, please explain what it is that does not work the way it should. > > -- > Viktor. > I think I understood what I need, is it possible to send an email defer when I receive a greylist error? I thought that with the command "queue_run_delay" I could solve this but not. Regards,
Re: Greylisted for 300 seconds and queue_run_delay
On Tue, Aug 04, 2020 at 05:47:35PM -0300, SysAdmin EM wrote: > > If you do believe there's actually a problem, i.e. something actually > > goes wrong as a result of trying to delivery 4XX failures on a second MX > > host, please explain what it is that does not work the way it should. > > I think I understood what I need, is it possible to send an email defer > when I receive a greylist error? I thought that with the command > "queue_run_delay" I could solve this but not. No queue_run_delay has nothing to do with whether a second MX host is tried when the first responds with a 4XX error. It just controls how often qmgr(8) scans the deferred queue. Since you've not (yet?) explained what problem you're trying to solve, I'm not (yet) prepared to offer a (half-baked) solution. -- VIktor.
