Hi Hector,
Thanks for sharing your thoughts.
There is nothing that says one is better than the other. All it is is a
pool for the sender to use. The preference is just that, a "hint" for
the sender to begin with. The sender concern is delivering the mail to
the destination - period. How the host farm of receivers is
inconsequential.
That is not consistent with RFC 5321: "MX records contain a preference
indication that MUST be used in sorting if more than one such record
appears". [ http://tools.ietf.org/html/rfc5321 ] So the receiving party
can expect that the MX with the lowest preference number is tried first
by a well-behaved sender. If you want "just a pool", give them all the
same preference number.
Also consider the advent of GreyListing Servers where the first attempt
is automatically rejected with the expectation there would be a 2nd
attempt by the client. There is not concrete rule that says what each
MX expanded set of IP means to the sender other than they represent a
pool of available servers.
That is true, although personally I don't like GreyListing that much.
[ http://en.wikipedia.org/wiki/Greylisting#Disadvantages ]
If a host has its own "special" rules for filtering/moving data
differently, then thats on it only. Senders has no idea or guideline
there other than the preference order but that should NOT make a
different what the actual order of machine calls is. They all must
ultimately do what is expected, delivery/relay the message to the target
address.
Yes it MUST make a difference in the actual order of machines tried by
the sender, see RFC 5321. Of course the actual result can diverge from
what is tried.
I think the "backup" concern was basically a secondary connection
concept - a 2nd place to go just in case the first machine was down or
that connection was failing.
Indeed. All I really wanted was something to punish senders that do not
even try to send their mail to the MX with the lowest preference number.
Regards,
Evert
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp