[Top] [All Lists]

Re: [ietf-smtp] Reject messages on backup mail exchangers when primary MX is online

2013-03-04 09:04:20
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:

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.

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>