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

From: "Robert A. Rosenberg" <[email-masked]>
Date: Sun, 3 Mar 2013 23:30:54 -0500

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. 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).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 3 Mar 2013 22:55:06 -0800

Indeed:

http://tools.ietf.org/html/rfc6647#section-4

-MSK

On Sun, Mar 3, 2013 at 8:30 PM, Robert A. Rosenberg <[email-masked]>wrote:

> At 07:48 -0500 on 02/27/2013, hector wrote about Re: [ietf-smtp] Reject
> messages on backup mail exchangers w:
>
>
> 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. 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).
>
> ______________________________**_________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ietf-smtp<https://www.ietf.org/mailman/listinfo/ietf-smtp>
>

---

From: hector <[email-masked]>
Date: Mon, 04 Mar 2013 10:02:07 -0500

On 3/3/2013 11:30 PM, Robert A. Rosenberg wrote:
> 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 

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