In message <53d133d4.4020...@chrysler.com>, Kevin Darcy writes:
> So, if the TTL on the record were higher than the queue-expire setting
> of the MTA, wouldn't the *intelligent* strategy be to promote the
> tempfail to a permfail? I've never written an MTA, but it seems like an
> obvious optimization to me.
>
> - Kevin
I doubt that it is worth the effort. If one was doing this the ttl
is likely to be very small (< 60) so that there are minimal effects
when you do reconnect.
Mark
> On 7/23/2014 10:00 PM, Mark Andrews wrote:
> > 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 thi
> s
> >>> 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
>
> _______________________________________________
> 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
