On 2/23/2013 3:23 PM, Evert Mouw wrote:
Not even close. See above. At most the role of a check of the primary would
be the adjust spam filters and perhaps some rate limiting.
I'm not going to bother to respond to your specific proposals since IMO the
entire goal here is wrongminded.
Well, you seem to agree with the others on this list, so what can I say?
It was just an idea... It's hard to get rid of the spammers ;-)
It's too unfortunate that we have to calculate in that routing problems
could result in the primary MX not being reachable from the sender,
while a backup MX will still be reachable. I believe that such a
situation would be highly unlikely in many cases, but I agree that a
standard should cover all cases and be consistent with other standards.
There is really nothing primary vs backup as far as the mail sender is
concern.
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.
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.
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.
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.
Personally, what would have been interesting explore a few years back is
a system that advertises host availability for different classes of
senders (content). Private versus Public, e.g. ISH or International
SPAM Hour perhaps to help in better delivery, lesser overhead and even
open the door to allow spammers to exist (under friendly terms).
So its possible to have a discovery method where a site can define
"corporate" MX1 machine(s) and also define the PUBLIC/SPAM MX2
machine(s). We can probably do this under the current MX framework by
providing range definitions to the preference numbers and ranges.
Nonetheless, even with advanced interpretations and methods, we still
need to support the basic idea of pools of machines or receivers to
deliver mail to. That is all the MX provided. Anything special on the
receiver end was not important to the sender.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp