--On Tuesday, September 09, 2014 13:18 -0400 Hector Santos
<hsantos(_at_)isdg(_dot_)net> wrote:
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.
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.
"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."
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.
"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?)
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp