Subject: [ietf-smtp] draft-klensin-smtp-521code-02.txt

From: John C Klensin <[email-masked]>
Date: Sun, 07 Sep 2014 12:28:57 -0400

Hi.

To promote tidiness, I've just posted
draft-klensin-smtp-521code-02.txt.   It responds to an extended
discussion on the Apps-Discuss list and some on the IETF llst
about the new nullMX spec, error codes, and RFC 1846.  The scope
of the draft itself is intended to be quite narrow -- it updates
RFC 5321 by adding two codes, 521 and 556, to SMTP and defines
the uses for both.  In particular, it takes no stance on whether
dummy servers such as those proposed in 1846 or nullMX DNS
records should be used at all.

I've directed discussion toward this list on the theory that the
substance of the I-D is really an SMTP matter.  I assume the
draft will be handled as an individual submission.

best,
    john

---

From: Hector Santos <[email-masked]>
Date: Tue, 09 Sep 2014 13:18:22 -0400

Hi John,

I've been out of the loop on this, so am just reading this as a "new 
reader" and potential implementor.

I think there is two much details already.  Just keep it simple.

    "Here are two new codes:"

    521  proposed text for 521
    556  proposed text for 556

and just explain each one and when/why it can used.  This should be an 
addendum "insert" for a RFC5321 "manual."

It sounds to me that 521 is for "dummy" servers. You won't use this 
for no other reason but to tell the client what?

    "Do not call this DOMAIN again."  or
    "Do not try this IP again."

I think we are talking DOMAIN.    The question I have is whether it is 
really a PERMANENT thing?  or it just for the transaction only?  A 521 
does not tell clients the attempted DOMAIN is a permanent "no mail 
server" domain?  Or does it?  (Will it be used that way as a way to 
help control mail blasters?)

Anyway, write this doc for people including those like me who are on 
the engineering IETF side-lines.  You guys already "know" whats 
happening with the devil details. The "layman" software keeper of 
established SMTP software just want to know the basics for plug and 
play operations/cost/changes.

Thanks

On 9/7/2014 12:28 PM, John C Klensin wrote:
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Sep 2014 22:05:45 -0400

--On Tuesday, September 09, 2014 13:18 -0400 Hector Santos
<[email-masked]> wrote:

> Hi John,
> 
> I've been out of the loop on this, so am just reading this as
> a "new reader" and potential implementor.
> 

While I'm sympathetic to the principle, I don't see how to do
what you are suggesting.  Section 1 is just context and
boilerplate.  Section 2 could be discarded, but it would be hard
without it to figure out what this is about.  Sections 3 and 4
are, AFAICT, more or less what you are asking for, but in the
form needed as a basis for updating 5321 and explaining why that
is necessary.  5.1 is needed to update 5321, and 5.2 is needed
to avoid confusing instructions/advice about 521 and other
things between this document and RFC 1846.
 
> and just explain each one and when/why it can used.  This
> should be an addendum "insert" for a RFC5321 "manual."

But the problem is that there is no RFC5321 "manual", there is
only 5321 and it has a particular way of organizing and
presenting error codes.  If this document updated it without
following that model, we would be likely to introduce other
problems.  

> It sounds to me that 521 is for "dummy" servers. You won't use
> this for no other reason but to tell the client what?

I can't quite parse that sentence.

> I think we are talking DOMAIN.    The question I have is
> whether it is really a PERMANENT thing?  or it just for the
> transaction only?  A 521 does not tell clients the attempted
> DOMAIN is a permanent "no mail server" domain?  Or does it?
> (Will it be used that way as a way to help control mail
> blasters?)

That is a different version of the primary reason for splitting
the two codes (a Postfix idiosyncrasy is a separate reason).  If
521 comes out of a dummy server, that server cannot reliably
know its domain name (or, more specifically, the domain name
through which it was accesses given, e.g., that anyone can
create a CNAME pointing to anything else or even connect to a
host by IP address.  Remember that all the tests SMTP makes
about match domain names, the requirement for primary names,
etc., are either requirements on the DNS or on the MAIL or RCPT
commands, not initial connection.   So the answer is "host" or
perhaps "interface and port", but not "domain".

As to permanence, nothing is ever permanent, but I certainly
would not go to the trouble of setting up a dummy SMTP server
unless I didn't intend to receive mail on the host for a really
long time.  If I intended to have a regular SMTP server with a
"not available right now" switch, the intent of 5321 is very
clearly that, when that switch is turned on, a 4yz code
(presumably 421) be returned, not 521.  521, like any other 5yz
code, means "permanent failure", at least as "permanent" is
defined within the 5321 context.

By contrast, 556 is a report about some indirect information
that SMTP connections are not accepted and it, necessarily, is
about domains.

> Anyway, write this doc for people including those like me who
> are on the engineering IETF side-lines.

Interestingly, your question about permanence says that there is
too little, rather than two much, text in the document.

>  You guys already
> "know" whats happening with the devil details. The "layman"
> software keeper of established SMTP software just want to know
> the basics for plug and play operations/cost/changes.

Then read Sections 3 and 4 only and ignore everything else.  I
actually don't think that works because I think the "layman"
can't get SMTP reply handling right without a reasonable
understanding of Sections 4.2 and 4.3 of RFC 5321.  And I can't
write the document in the simple "if you are going to do X, use
code Y" form you are asking for and still update 5321.  

If you see a way out of that set of problems, send text.

  best,
    john