Thanks for the heads up on this. I've just set our mail servers to watch
out for this and treat it as a 5xx. I hadn't noticed, but if I'd ever
noticed a 4xx on "Relay access denied" I likely would have added this
logic immediately without even taking time to second guess it, as I
can't think
To update this thread, the same problem with https://olcsupport.office.com/
continues, been a few weeks now.
If anyone knows of an alternate way to reach microsoft since that form
is no longer usable, please share.
Thanks for your patience, we are currently experiencing technical
Bill Cole via mailop skrev den 2023-10-09 14:45:
On 2023-10-09 at 03:46:08 UTC-0400 (Mon, 9 Oct 2023 07:46:08 +)
Gellner, Oliver via mailop
is rumored to have said:
Postfix default of the maximum queue lifetime is 5 days:
https://www.postfix.org/postconf.5.html#maximal_queue_lifetime
One
On 2023-10-09 at 03:46:08 UTC-0400 (Mon, 9 Oct 2023 07:46:08 +)
Gellner, Oliver via mailop
is rumored to have said:
Postfix default of the maximum queue lifetime is 5 days:
https://www.postfix.org/postconf.5.html#maximal_queue_lifetime
One month is very long, but I usually see systems to
On Mon, 9 Oct 2023, Simon Arlott via mailop wrote:
On 09/10/2023 07:44, Kirill Miazine via mailop wrote:
The reason for a long retry is that I have to manually decrypt mailstore
partition in case of server reboot. Exim would accept the message, but
defer delivery until the mount appears. I
I guess discussing my setup (retry rules, queue lifetime or encryption
setup) is not strictly on the topic, but I'm commenting it further:
• Slavko via mailop [2023-10-09 09:34]:
Dňa 9. 10. o 8:44 Kirill Miazine via mailop napísal(a):
The reason for a long retry is that I have to manually
• Simon Arlott via mailop [2023-10-09 09:12]:
On 09/10/2023 07:44, Kirill Miazine via mailop wrote:
The reason for a long retry is that I have to manually decrypt mailstore
partition in case of server reboot. Exim would accept the message, but
defer delivery until the mount appears. I wanted to
On 09.10.2023 at 08:24 Robert Mueller via mailop wrote:
>> I see that current setup might be useful in case some user changes MX
>> before the domain is activated at Fastmail, in which case giving 4xx
>> could make sense. But it is not right to report such re-tries to
>> sender score as attempts
Dňa 9. 10. o 8:44 Kirill Miazine via mailop napísal(a):
The reason for a long retry is that I have to manually decrypt mailstore
partition in case of server reboot. Exim would accept the message, but
defer delivery until the mount appears. I wanted to have some time in
case of a reboot and me
On 09/10/2023 07:44, Kirill Miazine via mailop wrote:
> The reason for a long retry is that I have to manually decrypt mailstore
> partition in case of server reboot. Exim would accept the message, but
> defer delivery until the mount appears. I wanted to have some time in
> case of a reboot
Am 09.10.2023 um 17:23:33 Uhr schrieb Robert Mueller:
> It's better that it actually bounce sooner to let the sender know
> that something went wrong rather than trying for a month and the user
> not knowing that their email is in limbo somewhere.
I don't know postfix´s default, but sendmail
Hi, Rob
Thanks for your email and for confirming my theory.
• Robert Mueller via mailop [2023-10-09 08:23]:
I see that current setup might be useful in case some user changes MX
before the domain is activated at Fastmail, in which case giving 4xx
could make sense. But it is not right to
> I see that current setup might be useful in case some user changes MX
> before the domain is activated at Fastmail, in which case giving 4xx
> could make sense. But it is not right to report such re-tries to sender
> score as attempts to deliver to non-existing users.
Yes, this is why we
13 matches
Mail list logo
