Racer X wrote:
> part of the problem, for me at least, is that it is impossible to guarantee
> that secondary MX's will, in fact, accept mail for the domain they are
> supposed to be MX'ing for. i'd rather hold the mail for a couple days in my
> queue and deliver it directly to the host than pass it off to a secondary
> that may or may not handle it correctly. at least if i pass it directly to
> the host i can guarantee that it's his fault if he loses it then, as opposed
> to getting a third party involved.
So in all scenarios, you'd prefer to ignore all MX entries but the lowest?
Wouldn't your argument apply equally to every failure scenario?
I see the merit in your argument. I don't see how it distiguishes between
differnet failure scenarios that need to be acted on differently.
> the more i think about this, the more i think that fallback MX records
> aren't really necessary anymore. having 3 or 4 fallback MX hosts was nice
> 10 years ago when mail could be passed in pony express format, eventually
> making its way across the country by store-and-forward, when everyone ran
> open relays and cooperated to help the mail get through. that really just
> isn't the case anymore for a large part of the world.
This is a good point for most servers.
Many people are still running servers on dialups that don't get connected
all the time. I do MX-ing for a couple of them. When they are connected,
it's for a few hours or more at a time, so they will soon get their mail.
It can be argued that they should pick up their mail from my server instead.
But the way it works now works just fine and is the least administrative
burden (I don't have to add all their userids and worry about collisions).
Probably the best counter argument is that the world should see my server
for their domain as the only one, and my server should see their server
as the one. It's a fair argument. I just haven't put it up like that as
I am still thinking about what is the best way to manage more than one
DNS server with different data for the "same" zones.
> there is very little reason for most MTAs to pass mail to a secondary MX
> host. if it can't be delivered to the primary, it's fairly likely that it
> can't be delivered to the secondary either. moreover, today anyway, it's
> likely that the secondary will be improperly configured and will refuse to
> accept mail for a domain it's supposed to be MX'ing for. further, it's
> quite possible that the secondary won't be able to deliver any sooner and
> may ultimately take longer to deliver.
I also find it quite likely these days that the _primary_ is also misconfigured.
It is a fair argument to suggest that an effort be made to ensure reliable
delivery even in the face of the recipient's server's being misconfigured.
I would also suggest that they should remove their secondary MX record if
they don't have a procedure in place to verify that the secondary host is
correctly configured.
OTOH, if we always skip the primary and go only to the last secondary, then
they will be forced to be sure all their servers are up to snuff.
> > How is it that people won't notice the breakage if the primary mail server
> > isn't accepting mail? If the server accepts connections, and then keeps
> > closing them, it's not going to get its mail even from then secondary MX.
>
> so why even attempt to pass the mail to the secondary in that case?
> ignoring the firewall issue, to qmail it looks like the primary host
> accepted a connection and then dropped it abruptly. why should qmail think
> the secondary MX will have better luck?
In some situations, the secondary may have a means to ensure that it can get
connected. Maybe the source IP address is used by the primary to decide.
In other situations, the secondary may not be able to do any better right now,
but it might be able to later on at a time when you cannot even reach either
(for perhaps unrelated reasons).
The set of possibilities is at least large. I just tend to favor the notion
of getting the mail as close to its destination as soon as possible.
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
