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 report such re-tries to sender
score as attempts to deliver to non-existing users.
Yes, this is why we 4xx rather than 5xx email sent to an unconfigured domain.
Many inexperienced email users aren't sure exactly what order to change or set
things up in and we've seen users lose email before because they changed the MX
records before adding their domain at Fastmail. The 4xx response reduces the
chance of lost email.
Exactly what I was thinking, yes.
In general it doesn't really matter that it's 4xx not 5xx. There's no sensible
reason to point MX records for a domain to us if you're not planning on
actually using us for your email. If that does happen, the email will
eventually bounce when the other side gives up trying to resend, which in most
cases is at most 24 hours.
Now clearly there's an interesting and unexpected edge case that's happened here. The
logging of repeated delivery to a "non-existent" address has been rolled up
into a sender score feed that's affected your servers IP reputation, which is really
annoying.
It is. And if mailing volume would be huge, those retries wouldn't
matter for the score, but I don't, so, yeah.
Unfortunately fixing the code on this is non-trivial right now since in the
policy daemon where this logging occurs we don't actually have the information
we need to suppress this case there and then. I have some longer term ideas for
this, and will keep this scenario in mind when I get to them.
Sorry Kirill, I don't have a really good answer right now, though I would say that
"emails would be kept in the queue for a month" is probably actively working
against you here. There's no reason an email should be queued for that long. 24 hours
seems a high upper bound these days and is the postfix default. 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.
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 not being easily available to mount the partition.
I guess I'll have to work with sender score to have them re-set the bad
score.
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
