On 7/17/2014 10:39 AM, John C Klensin wrote:
Hi. For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful.
Since I'm the doc shepherd:
I have not seen statements by others indicating that the
specification is 'distasteful', although there have been some that
seemed to confuse its functionality with that of SPF.
Feel free to cite the specific comments by others that classed this
as distasteful or the equivalent.
I see it as another step, albeit a small one, in
the direction of prioritizing the prevention of unwanted
messages or connections over successful delivery of legitimate
messages.
A statement of "I don't do X" does not 'prioritize' anything.
The use of information that says "target address Y will not work because
there is not receiver at Y's domain" does not 'prioritize' anything.
The specification is nothing more than a vastly more efficient form of
getting an SMTP 550 Requested action not taken: mailbox unavailable,
except that it is even better than that, because it also precludes
waiting days to discover that there's no service to supply even that
error message.
Hope, it would be better if the specification were historically
accurate and accurate about the protocols it cites.
You do not clearly indicate any historical inaccuracy at issue.
The last sentence of the second paragraph of Section 5
("Security Considerations") of the spec says:
"The normal way to send mail for which a sender wants no
responses remains unchanged, by using an empty
RFC5321.MailFrom address."
First, two issues of terminology:
(1) RFC 5321 does not contain or specify notations like
"RFC5321.MailFrom". That notation was introduced in RFC 5598, a
document that was approved as Informational with a consensus
that, IIR, included some significant desire that it not be
normative or casually treated as normative. If this
First, so what?
Second, a review of the IETF mailing list archive about the document's
Last Call, in May of 2009, shows a nicely solid pattern of support for
the document's publication. Strange that you would call it into
question at this point.
specification wants to use that notation, that is fine. But it
should include an explicit note to that effect in its
introduction or a Terminology section, not bury a "(see
[RFC5598] for the definitions of these terms)" reference in a
parenthetical note in Section 4.1 and then expect readers who
are looking specifically at other sections to pick up on it.
If you want specific text changes, please suggest specific text changes.
Please do not formulate a requirement for change in a fashion that
leaves the authors having to guess whether it will satisfy you.
I believe that the RFC Editor's principle is that, if particular
terminology is needed to correctly understand a specification,
then the reference to the document that defines that terminology
is normative. In this particular case, it seems inconsistent to
consider 2119 normative and 5598 informative since both are used
to define terminology without which the document cannot be
correctly understood.
So, you are suggesting that RFC 5598 be a normative reference here?
(2) Second, RFC 5321 does not contain a concept that it calls an
"empty address". The terminology it does use is "null
reverse-path" (See RFC 5321, Section 3.7). Subject to the
above, if the authors want to say "null address in
RFC5321.MailFrom", I don't think that is sufficiently confusing
to be a problem. But "empty address" could be construed as
MAIL FROM:
in the envelope with nothing following it, and that would be bad
news.
So you are suggesting:
empty RFC5321.MailFrom address
->
null ("<>") reverse-path, per 3.6.3 and 6.1 of RFC 5321
More important, however, RFC 5321 specifies the use of a null
reverse path only for delivery failure and status notifications
and message disposition notifications (see Section 4.5.5 of RFC
5321) and constrains the recipient address to be used. That
section also says
"All other types of messages (i.e., any message which is
not required by a Standards-Track RFC to have a null
reverse-path) SHOULD be sent with a valid, non-null
reverse-path."
And here I was, thinking that "SHOULD" means it is ok /not/ to do what
is being directed, if you have a good reason. Oh, wait...
Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL
MX Resource Record". There is only an MX Resource Record that
this specification proposes to use with a convention involving
specific content in the DATA. One could call that many things,
but "NULL MX Resource Record" isn't one of them.
By my reading of that section, it is defining the term, if only by
virtue of the way it is used in the name of that section.
Perhaps your confusion would be resolved if the term had a comma in it,
so: NULL, MX Record?
In other words, NULL is an adjective within the term.
If you would prefer a different term, please suggest one.
(b) I think I know what the second paragraph of 4.1 in intended
to convey but I have now read it several times and can't be sure
that it what is says. The parenthetical terminology note
doesn't help with readability but the problem exists even
without it.
Take a look at the sub-section's title. Note that the first paragraph
reviews benefits for an SMTP client and then note that the second
paragraph extends into talking about a particular benefit for a
receiving SMTP server, per the section's title.
NullMX allows a receiving SMTP server to detect when a return-path
address uses a domain name that does not receive mail. Hence, at
submission time, the receiving server can reject such messages.
(e) The issues identified above aside, the explanation in the
second paragraph of Security COnsiderations (Section 5) is
unsatisfying. If a domain is configured so that some sending
hosts don't receive and some receiving hosts don't send, the
model specified in this document may simply be inappropriate and
shouldn't be used lest it cause lost messages. Why can't that
simply be said, and said clearly (probably in another section
referenced from this one.
How would that be better than what is in the current draft?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net