Re: [ietf-smtp] Reject messages on backup mail exchangers when primary M

On 2/24/2013 3:57 AM, Evert Mouw wrote:
> 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.
It all a pool, which is what many do but only from the standpoint of 
preferred machines to reach first. It really has nothing to do with 
filtering is what I am saying, so despite the order of machines, all of 
them must ultimately be equal in terms of sender expectation for 
acceptance and delivery.  It really doesn't matter who is called first 
or last. The host playing games with whatever logic to alter 
classification of senders is entirely up to them. but whether it was 
MX-FIRST or MX-LAST that was tried by the sender, if the mail is 
received, the senders job is done and the expectation for delivery is 
intact.    There should be no difference that MX-LAST receiving the mail 
first is going to be any different than MX-FIRST receiving the mail 
first as preferred by the host system.
> That is true, although personally I don't like GreyListing that much. 
> [ http://en.wikipedia.org/wiki/Greylisting#Disadvantages ] 
Been developing and using greylisting for 9+ years in our package and 
everyone loves it.  You have to make it work for your customers with 
advanced fast whitelisting ideas and with support for advanced "Smart" 
MTA ideas like SMTPGREY 
(http://tools.ietf.org/html/draft-santos-smtpgrey-02) its fits in better.
Nonetheless, we like it or not, it is out there and it only because the 
idea of using different MX for different things was not really 
expected.  I sincerely doubt Greylisting would of taken off as it did if 
such was the case. I know I would have never bother to develop for it 
and implement in products,  which was done reluctantly.  A waste of time 
if there was an MX idea that the secondary forced call could be 
problematic.  I would had never supported Greylisting at any level. 
Don't think so, nor do I think would it has been pursued by many.
> > 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.
Yes, but I hope we can agree that it ultimately doesn't matter, 
otherwise we will have a real problem out there and I don't think we do, 
in this regard.   Retry strategies are complex.   You have to have a 
Retry concept and having a pool of different paths or just a different 
computer is fundamentally required. Fortunately, with hardware 
advancement, at least among smaller operators or sites, its one or two 
single machine it runs 24x7x365 and if down, at least downtime at 4-5 
days or so.  The super major majority (over 95% in my view) has been 
able to handle that - otherwise, email would never had exploded like it 
did.  :)
> > 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.
With the current framework, this would hurt the SMTP transport and 
delivery process as we know it today.  It will also alter Queuing 
Strategies, in my design opinion, drastically.   In other words, it 
would "punish" the good guys too, and that include those who have 
advanced queuing methods.
I think the better approach is to "teach" the MTA how mail can be 
received and delivered more efficiently without wasted retries and 
delays.  New SMTP extensions that attempt to inform clients about 
server/hosting attributes.  That will probably mean a new DNS Server 
Policy discovery concept like the old Fidonet NODELIST which provided 
clients delivery times and whats was allowed to be transferred to 
servers.  It even told clients when to use the BACKUP routing path 
guaranteed by FTSC policy to be always deliverable. The SMTPGREY  
proposal attempts to provide some reject intelligence to help the MTA 
reschedule its 2nd try.  We have proof of concept that it indeed works 
in practice.
But this extension to more about reaching a higher success rate with 
minimal attempts, i.e. making it at the 2nd attempt at most.   What you 
are proposing is to maximize success at the 1st attempt.
This is why its a complex queuing issue.  Suppose I have 1000 messages 
for 1000 people at the same domain?  How will you do the sending?  Do 
all go to the first MX?  Do you spread it?  Are you shooting for fast 
throughput? What is the better queuing strategy? Does one fit all?  Does 
all receivers behave the same?   etc, etc.     If your idea was to make 
that MX-FIRST better than MX-LAST,  I think it will drastically change 
how mail is moved.   If one is punished by trying MX-LAST (and how do 
you monitor this btw?), then rest assured  many won't bother trying 
these last MX expanded ips.  They will just try the retries at the 
MX-FIRST sites.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp