On 3/3/2013 11:30 PM, Robert A. Rosenberg wrote:
At 07:48 -0500 on 02/27/2013, hector wrote about Re: [ietf-smtp]
Reject messages on backup mail exchangers w:
Your proposal/suggestion can hurt a working system IMO. It can't simply
assume that the first MX will be available at all times or that it will
be the first IP tried at all times. The specs may imply the caller MUST
sort and by implication call the first IP, but it would seem odd to me
to design anything around that. It would be so unreliable. You can't
enforce it or guarantee that this order is persistent or consistent.
One addendum. With gray listing, with the first attempt automatically
getting rejected with a Try Again status, a good queuing method should
be designed to be aware that such a Try Again response COULD be a sign
of Gray Listing and compensate for it.
That is the goal of the I-D SMTP extension SMTPGREY attempts to provide
- "intelligence" for the smarter client to leverage server response data
in "optimize" MTA rescheduling, to make sure the 2nd call is successful
and only a 2nd call is needed.
This means that if the initial attempt is made to a MX pool (ie: There
is more than one MX at the lowest priority) to record which IPN was
used and do the retry to it not some MX randomly selected from the MX
pool. Otherwise when you end up with a different MX IPN, it may blow
you off again due to Gray Listing (ie: There is no way to know if the
MXs share a common list of messages that have been Gray List blown off
on the first attempt so they will accept the second attempt even if it
is made to a different MX or if each have their own list so you will
keep getting blown off until by chance you finally connect with a MX
who has already blown you off and is thus willing to accept you this
time).
Yes, but, IMO, this is a different problem; mis-configuration and/or
outsourcing your mail needs or using other 3rd party MX. It would be
known of possible different paths having different results or it would
be a poor/odd setup/operation if the MX pool, regardless of "order" do
not provide equal acceptability (and rejection for that matter)
capabilities across the (MX pool) board. Systems like that, IMV, either
has more problems or more work for themselves or give others more
problems and work when it comes to mail.
I think we are talking about the need for protocol and software
automation - making them work with the state data provided and also as
expected to be maybe available on/for both ends. It sounds there might
be many definitions of what the MX was suppose to offer. I don't think
it was for mail filtering.
A while back, I had an idea to using the actual domain host names of the
MX themselves to mean different things. Preference was the only extra
data you can get from it now for sorting purposes only. There was an
suggestion for preference zero to mean something - no mail I believe???
I forget, but why not use the subdomain names themselves, like for example:
bus-mail-only.mx1.example.com
auth-req.mx2.example.com
for-spammers-only.mx3.example.com
etc, get the idea?
The idea would be to use the literal sub-domain for some formal syntax
to that can easily detected by clients and have some real offering for
all parties. Spammers won't bother with the mx1 and mx2 ips because it
knows it will be a waste of time. A pool is provided to them.
I guess we can also use the MX preference with special ranges to have
similar interpretations, but its not backward compatible.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp