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