In message <53cfbb29.7040...@chrysler.com>, Kevin Darcy writes:
> Potentially dumb question: what does this "magic meaning" MX target
> (".") offer, that a target resolving to a null address (0.0.0.0 and/or
> ::0) does not? No protocol or code changes required.
>
> The null address does, after all, mean "no service offered here". (Now,
> if only load-balancer vendors could wrap their tiny minds around that
> concept!)
>
> - Kevin
0.0.0.0 and :: mean "I offer service but I don't currently have a
address / know my address". This is a temp fail rather than a
permanent fail along with a ttl to retry the address lookup.
> On 7/17/2014 4:59 PM, Dave Crocker wrote:
> > 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/
> >
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
