ietf-smtp
[Top] [All Lists]

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

2013-02-27 06:50:11
The main point I wish to make is that there is no calling order that anyone can make a correlation with for filtering as you are proposing. At least, not anything reliable. For the sake of robustness, your system of receivers is not going to break down if there exist a suite of different queuing and mail distribution strategies, including one who behavior is to distribute the MX loading. I hope not.

A second minor point is that the RFC does not describe complete queuing strategies. Does the referenced RFC statement also imply that a sender MUST called the first MX at each subsequent delayed re-send attempt? What if there are already 4-5 connections on that channel?

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.

---
HLS

On 2/27/2013 6:57 AM, Evert Mouw wrote:
On Wed, Feb 27, 2013 at 12:44:31AM -0500, Robert A. Rosenberg wrote:
At 20:00 +0100 on 02/26/2013, Evert Mouw wrote about Re: [ietf-smtp]
Reject messages on backup mail exchangers w:

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?
The answer is in the RFC I have quoted earlier for you. All 1000
messages MUST be tried by the client using the first MX. Hate it or love
it, but that is what the RFC 5321 is for.
Are you defining "First MX" as the first MX in the list (assuming
that the list is sorted in ascending order of the priority entry) or
the pool of MXs with the lowest priority value? So long as you
spread the 1000 messages over the lowest priority MXs (assuming that
there are more than one MX with the lowest value) you are following
the RFC. In fact with Threading of the sending, you would flush the
queue faster if you spread the messages over all the MXs than just
single stream them through one MX session. IOW: Round-Robin the list
of MXs with the same lowest priority value.
Absolutely. A pool of MXs with the same preference number can (and in
fact MUST) be used at the same time. However, Hector stated on the subject
of multiple MXs with different preference numbers: "The answer is not in
the RFC." And again I have to refer to RFC 5321:

MX records contain a preference indication that MUST be used in sorting
if more than one such record appears (see below).  Lower numbers are
more preferred than higher ones.  If there are multiple destinations
with the same preference and there is no clear reason to favor one
(e.g., by recognition of an easily reached address), then the
sender-SMTP MUST randomize them to spread the load across multiple mail
exchangers for a specific organization.

Just to clear things up.

Regards, Evert

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

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