I just sent an email to -advocacy where I spelled the list name wrong. I
did not get a bounce. Why? Because the mail system is (again or still)
broken in it's config. What happens is:
1) Tries to deliver to svr1.postgresql.org. This machine response that the
user is unknown, *but does so with a 450 error code indicating that this
is a temporary error*. This is of course wrong, it should be responding
with 550.
1b) Also, that machine is supposedly named "postgresql.org" for some reason
that I don't really understand. But the MX rcord still points to svr1,
which is an alias. (I don't say this should be fixed, because I don't see
the point in not calling the machine svr1, but that's probably just because
I've forgotten the reason for it :-P But either way, it should be
consistent)
2) Since it got a 450, it tries a secondary MX, in this case mx3.hub.org.
Now:
2a) Why do we even bother with secondary MXes since all they do is relay
back to svr1 anyway? It doesn't actualliy *help* us anything that i can
see, it only makes the configuration more complex.
2b) If we do relay, then the secondary MX must *also* know the list of
users, so it can give a proper bounce. What happens now is that my email is
queued up on mx3.hub.org and will stay there as it retries over and over
for a couple of days, when the bounce will be generated on that system.
2c) mx3 is then *graylisted* by svr1. A backup MX must *NOT* be graylisted
by the primary machine. I know I have mentioned this several times before
wrt other machines.
3) At the risk of soundling like a real broken record again, we really
need *some kind of basic documentation* of this system.
Our mail infrastructure is critical to the project. We simply cannot afford
having one that looks like this.
My suggestion is the same as before - de-couple it from the hub.org
infrastructure, thus making things a lot simpler and less likely to break.
If this is for some reason not acceptable, can we please, and *urgently*,
have these issues listed above fixed?
//Magnus
