ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Telechat update notice: <draft-klensin-smtp-521code-05.txt>

2015-03-12 10:54:03
(distribution significantly trimmed)

--On Thursday, March 12, 2015 08:59 -0400 Hector Santos
<hsantos(_at_)isdg(_dot_)net> wrote:

Hi John,

Reading the abstract of this document only, it was clear to me
about the intent of the codes and good to add to our SMTP
package.  But is there a translation of what it means on the
SENDER SIDE?   Is it permanent filter/block at the domain
level?
...

Hector,

Your note raises issues that we (taken very broadly) have
resisted specifying in SMTP since the beginning because they are
really operational necessity considerations and not protocol
ones.  Speaking personally, "Permanent" (for longer than the
lifespan of a message) has always given me the creeps:
configuration errors are made and corrected (sometimes after far
too long), configurations and systems change, and so on.  I can
imagine that, as free IPv4 addresses become less avaiable, some
ISPs will pull addresses from their former dynamic pools (pools
that are blocked by many blacklists) and assign them as static
addresses.   Even nullMX could be a problem if a DNS
configuration had a too-long TTL, minds were changed, and an MX
record that pointed somewhere useful were installed.  

Nothing in this document changes anything relative to
"permanent" blocks, nor does it offer advice on how long blocks,
once put in place on the basis of some set of failures, should
last.  If I were designing a system to minimize trying to probe
hosts that had announced they were not interested in receiving
mail today, I'd probably spend some time contemplating functions
of my retry duration but then get over that, pick a default, and
allow system operators to tweak that default.

Remember too that these code and nullMX are all intended to
reduce the need for permanent blocks and other measures that
might prevent mail delivery if conditions change by making it
cheaper to just ask (whether "ask if there is an SMTP Server" or
"ask the DNS").  So the existence of nullMC and these codes, if
implemented and supported, should reduce the need for servers to
figure out what to block and for how long.

best,
    john

---------- End Forwarded Message ----------




_______________________________________________
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>
  • Re: [ietf-smtp] Telechat update notice: <draft-klensin-smtp-521code-05.txt>, John C Klensin <=