ietf-smtp
[Top] [All Lists]

Re: Recipient is offline

2011-09-02 09:23:49



--On Friday, September 02, 2011 12:44 +1000 Mark Andrews
<marka(_at_)isc(_dot_)org> wrote:

...
That is one of several reasons why TURN was deprecated years
ago.

TURN is useful if the is not a direct incoming path.
e.g. Running multiple MTA's behind a firewall/nat that blocks
incoming connections.
ETRN is useful if the is a direct incoming path.

Mark, I said "it was deprecated".  I didn't say that there were
not arguments for keeping it for special circumstances, nor that
there were not other tradeoffs.  The WG considered those issues,
deprecated it, and introduced ETRN to deal with the pieces of
the problem that affected the public Internet.  And I was told
to put the text into 5321 that pointed out that using an inbound
email message to trigger a delivery attempt for messages in the
queue might avoid the need for ETRN (or TURN in some cases).  I
didn't make that up although I've seen it put to good use.

Horses for courses.  That said ETRN is probably more applicable
here as there is a direct incoming path.

Backscatter is a problem for any backup MX.

A lot of things are "problems" for any relay SMTP that does not
have access to information about what the delivery server will
do.  Of course, nothing in the protocols prevents the delivery
server from sharing lists of active mailboxes and their status
with the relay server.  If that were done, then backscatter is
no more of a risk with the relay server (or backup MX, if you
prefer) than it would be with the final delivery server.   The
situation is all about tradeoffs; I content that almost any
relay situation is, independent of protocol.

Note the "backup MX" may be the only MX listed to the public
and the backup MX can see lower priority MX records.

Sure.  And 5321 (and its predecessors) are quite deliberately
written to not require than an intermediate MX attempt delivery
over SMTP-over-TCP.  It is perfectly acceptable for it to
arrange to get the messages to the delivery system over UUCP, or
rsync, or, for that matter, semaphore flags, even if there are
lower-preference MX records in the DNS (public, private, or
otherwise).

    john

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