Subject: Re: [DNSOP] Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

From: John C Klensin <[email-masked]>
Date: Thu, 17 Jul 2014 13:39:53 -0400

--On Thursday, July 03, 2014 12:03 -0700 The IESG
<[email-masked]> wrote:

> The IESG has received a request from the Applications Area
> Working Group WG (appsawg) to consider the following document:
> - 'A NULL MX Resource Record for Domains that Accept No Mail'
>   <draft-ietf-appsawg-nullmx-05.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the [email-masked] mailing lists by
> 2014-07-17. 

Hi.  For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful.  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.  I continue to believe that prioritization is
undesirable, at least without fundamentally converting the email
infrastructure to an "acknowledge on delivery because there is
no expectation of successful deliveries" one rather than the
current protocols, which focus on notifications for
non-delivery.    That is not a strong technical objection and is
definitely not intended to be an argument against publication if
the IESG concludes that there is community consensus for doing
this, especially since, of the changes that could be motivated
as above, this is one of the more benign.

Hope, it would be better if the specification were historically
accurate and accurate about the protocols it cites.

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
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.

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.

(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.

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."

So. there isn't any "The normal way to send mail for which a
sender wants no responses" -- RFC 5321 and other specs
significantly constrain the cases in which null reverse-paths
may be used.  If this specification intends that notifications
that are generated in response to a null MX record, then that
needs to be made an explicit requirement to conform with the
language of RFC 5321.

Some additional observations that suggest this document needs
additional work before approval, probably with an intervening
additional Last Call:

(a) Sloppy DNS terminology has been the source of many problems
(see recent discussions of "dotless domains" in
draft-klensin-dotless-terminology-harmful; "hostname" used to
describe a DNS entry that contains an address RR, a DNS entry
where the owner also owns at least one address RR, and the first
(leftmost) component of an FQDN (with additional ambiguity as to
whether a zone break is implied); and considerable confusion
about terms like "resolver".  Whether the IETF steps forward to
try to clean up previous messes or not, it certainly should not
countenance making things worse.

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.  

I strongly recommend that, in the spirit of the cross-area
review we talk so much about, the IESG refer this document to
DNSOP for a careful terminology check and not approve and
publish it (or its successor) until that WG has affirmatively
signed off on the terminology used.   In particular, in addition
to expressing an opinion on calling "NULL MX" a Resource Record,
DNSOP should contemplate such sentences as "A domain MUST NOT
advertise multiple MX RRs including a NULL MX" in a DNS
terminology and confusion context.   Because DNSOP has no
identified milestones, such a review should be able to get at
least as high priority as anything else it is working on.  :-(

(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.

(c) In 4.2, to my aging eyes and using fonts designed for
readability rather than high discrimination, the last "or" and
the "rather than" appear to be identical.   The difference is
that the first one uses digit-one instead of the letter-l in
"example".  "examp1e.com" (with the digit) is a registered
domain name and not on the IETF list of domain names that are
reserved for and allowed in examples.  SO I recommend (and I
think IETF policy requires) that the example be changed and that
any similar valid one be better explained.  That paragraph
should also, IMO, explicitly point out that the claimed
advantages exist only if the holders of the domains that are the
targets of the "mistranscribed or misunderstood" names actively
cooperate in establishing these records.  Experience indicates
that many such domains are registered with the express intent of
capturing and taking advantages of mistakes; owners of such
domains would have negative incentive to cooperate.

(d) It seems to me that the cases this proposal addresses are
special enough that a dedicated Extended Status Code would be in
order.  Instead, the document specifies the highly generic 5.1.2
(even those the RFC 3463 definition of X.1.2 includes "incapable
of accepting mail" and "invalid for mail" (which don't mean
quite the same thing).   Especially since there is not an
easily-located WG discussion, the document should at least
explain its choice.

(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.

regards,
   john

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Jul 2014 09:35:17 +1000

In message <[email-masked]>, Dave Crocker writes:
> 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.

A better description of the record is "No Service MX Record" or "No
Service Offered MX Record".

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Jul 2014 20:39:38 -0700

> easily-located WG discussion, the document should at least

If consensus is to register a new code as suggested, one could certainly
help himself to a cloning of the useful parts of
draft-ietf-appsawg-email-auth-codes, now in Last Call.

-MSK

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jul 2014 11:53:00 +0100

Nico Williams <[email-masked]> wrote:
>
> I think what you're objecting to is the section 4.3 and related text
> that conflates "does not accept e-mail" with "does not send e-mail".

Section 4.3 describes what is already done by existing implementations of
this spec.

Exim in its default configuration validates the domain part of email
addresses and will reject mail if the sending domain does not exist or if
its MX records point to nonexistent hosts. Exim also recognizes null MX
records and suppresses the target A and AAAA lookups and treats the domain
as invalid. However the null MX logic is just an optimization: Exim's
validation logic would get the same result if it tried to do the A and
AAAA lookups and found that . does not have any addresses.

Postfix does the same if you use the reject_unknown_sender_domain option.

There are good reasons for rejecting mail from invalid domains, e.g.
because you would not be able to send a delivery failure report.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Variable 3 or 4. Slight or moderate. Thundery showers later. Good,
occasionally poor later.

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2014 08:55:26 -0400

Hi.

I have a few questions that I don't want to clutter the IETF
list about but about which I would hope DNS experts, especially
DNS root operations experts, would step in if they have
opinions.  IESG copied only for the record.   I want to stress
that these are questions: I may know enough to ask them but
can't even competently speculate on the answers.

The new specification proposes what is, in essence, a
convention.  If an SMTP-Sender (to use the original and very
precise terminology), while doing the required lookup for an MX
RR, encounters 

    IN MX 0 .

it is expected to abort the message-sending process -- no
further lookups, not connection attempts, no queuing.  

At least in the near term, some SMTP Server ("MTA")
implementations will conform to that rule (many already use it)
and some won't.   For the latter, they will presumably do what
the SMTP specs say to do.  In summary, that is to look up the
address(es) associated with the root and try to open a mail
connection to one of them.  When that connection fails
(presumably times out), the SMTP server may decide to try more
(or all) of the other addresses.  When all of those it chooses
to try fail, it is then required to queue the message, retrying
the process (potentially to all 13 root servers) at regular
intervals for an extended period of time.

It is impossible for me to estimate the actual likely volume of
such connection attempts.  I suggest that any such estimate
would be no better than a wild guess.  It is clear that the
requirement for retries and the number of root servers (i.e.,
that there is more than one address record) provides a
multiplier effect on the number of MTAs and misdirected messages
that do not follow the convention.

Given that the DNS configurations for some domains are using
this convention now, it should be possible to measure
present-day SMTP connection attempts to the root servers.  I
don't know if anyone has those data.  Because such attempts
could originate from multiple causes, it might also be hard to
interpret if it existed... beyond my experience.

So, three (obviously-related) questions:

(1) I understand that there have been concerns from time to time
about the load caused by spurious queries to the root servers.
These would not be spurious DNS queries (I assume primarily UDP)
but spurious TCP connections to a port that I assume no
contemporary root server uses to accept mail.  Is that potential
change in load an issue that anyone should be concerned about?

(2) Would you recommend that the root servers take any special
action to mitigate the potential problem?  Such action might
involve a port 25 responder that immediately closes connections
(at least reducing timeout waits), or a fake SMTP server that
would allow a connection to be opened, then immediately send a
5yz response to the SMTP sender.  If the SMTP specs are followed
by the sender, the latter would prevent attempts on other root
server address and the queuing behavior.  Either obviously
involves some additional resources.  

(3) Independent of the answer to the question above, does the
possibility of DNS operational impact as the result of this
convention merit comments in the I-D that are not now present
and, if so, what should be said?

Recommendation: if the participants in DNSOP consider either of
the above questions (and they are only questions) to be
significant, it may be worthwhile to ask the IESG to postpone a
decision on this document until this WG has an opportunity to
comment.

The above is obviously independent of the concerns about
terminology that I raised in my Last Call response.  As some of
you know, sloppy and ambiguous terminology in discussions of the
DNS has become a pet peeve of mine.  If no one else cares, or
cases enough to put effort into the problem -- even to prevent
new ambiguous usage from entering the vocabulary via IETF
standards track documents -- then I will go back to whining into
my beer and stop trying to waste other's time on the issues.

best,
     john

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Jul 2014 23:18:40 +1000

In message <[email-masked]>, John C Klensin writes
> address(es) associated with the root and try to open a mail

No.  Lookup the address _at_ _the_ _root_.  This is _not_ the
addresses of the root servers.

> intervals for an extended period of time.

What connection?  There are no addresses records at "." so the MTA
returns a NDN.

Mark

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jul 2014 14:22:21 +0100

John C Klensin <[email-masked]> wrote:
> connection to one of them.

There are no addresses associated with the root, so the mail server will
immediately report a delivery error. RFC 5321 section 5.1 paragraph 2
final sentence.

The SMTP server will not try to connect to the root name servers, as your
message suggested.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Variable 3 or 4, becoming northwesterly 5 or 6 for a time in east.
Slight or moderate. Rain or thundery showers. Good, occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 18 Jul 2014 06:46:42 -0700

> The SMTP server will not try to connect to the root name servers, as your

true as stated.

what's unstated here is that every SMTP sender who encounters such an MX
without understanding its new meaning will do two or three lookups: ".
MX", [". AAAA",] and ". A". if they are behind an RDNS that doesn't do
negative caching (and there are many, though none of them are open
source; the open source RDNS servers do negative caching right) then
these two or three queries will flow through to the authority servers
for "." which is to say the root name servers.

the long tail on old interpretation is between one and three decades.
(which is also why repurposing/redefining things like TCP/53 is
unworkable, as discussed separately.)

if IETF had rules, one of them should be, don't redefine things that are
in an existing datapath -- make a new datapath.

vixie

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2014 09:48:30 -0400

--On Friday, July 18, 2014 23:18 +1000 Mark Andrews
<[email-masked]> wrote:

>> implementations will conform to that rule (many already use
>> it) and some won't.   For the latter, they will presumably do
>> what the SMTP specs say to do.  In summary, that is to look
>> up the address(es) associated with the root and try to open a
>> mail
> 

I tried to make clear that I'm ignorant of many of the details
here, so, if there is no issue, I apologize for wasting people's
time. 

If the answer to those questions is "not an issue", that is the
answer and the end of the discussion.

However, because I'm paranoid, let me mention an issue in
passing without any reason to believe that it is a problem in
practice.

For SMTP (and at least some other applications) there has always
been a question about what to do with DNS queries in mixed IPv4
and IPv6 environments when the application wants to get both
sets of addresses.  I vaguely remember an idea about a query
type of "ADDEESS" (or equivalent) that would return both A and
AAAA RRs but, as far as I know, it didn't go anywhere.  If there
are best practices recommendations for applications writers in
this area, I don't think they have been widely disseminated in
the applications development community.  The poor bewildered
application author then has two choices, both of which appear to
be rational.  One is to issue two queries, one for A RRs and one
for AAAA, and then sort things out in the application.   The
other is to issue an ANY query and sort the relevant information
out from it.   I at least superficially understand the problems
with the latter and you obviously understand them much better.
But, should an application writer make that choice (and, again,
clear advice has not been broadly disseminated), a query for the
root does get back address records.

It is probably sensible to conclude that the number of
implementations that are that stupid doesn't make the issue
worth worrying about but that should be your conclusion, not
mine, because I am obviously out of my depth here.

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2014 10:13:30 -0400

--On Friday, July 18, 2014 06:46 -0700 Paul Vixie
<[email-masked]> wrote:

>...
>> There are no addresses associated with the root, so the mail
>> server will immediately report a delivery error. RFC 5321
>> section 5.1 paragraph 2 final sentence.
>> 
>> The SMTP server will not try to connect to the root name
>> servers, as your message suggested.
> 
> true as stated.
> 
> what's unstated here is that every SMTP sender who encounters
> such an MX without understanding its new meaning will do two
> or three lookups: ". MX", [". AAAA",] and ". A". if they are
> behind an RDNS that doesn't do negative caching (and there are
> many, though none of them are open source; the open source
> RDNS servers do negative caching right) then these two or
> three queries will flow through to the authority servers for
> "." which is to say the root name servers.

Paul,

Thanks.  I obviously got the question wrong but, if it
accidentally called attention to an issue that deserves even
minimal consideration, I don't mind looking and feeling stupid.
I obviously knew about the multiple queries but, by thinking
about this from an SMTP context, was more concerned about the
connection and queuing part of the problem.  

FWIW, many SMTP servers will deal with a negative answer from a
DNS query by queuing the message (for the historical reason that
a DNS change might not yet have caught up with the server
queried).  While the port 25 issue that I incorrectly focused on
will not arise, the two or three queries you mention might,
depending on the behavior of the resolver on which that SMTP
server calls, be repeated at each queue retry interval.

Again, I'm not competent to evaluate whether that is an issue or
not.

 thanks again,
    john

p.s. Just one or two lookups against the root.  The sequence
would be an MX lookup for the putative mail delivery domain
(which should not affect the root servers), then ". A" and,
optionally, ". AAAA", in either order.  While some
implementations have historically done it, SMTP (at least as of
RFC 5321) forbids doing an MX lookup on the information obtained
from the DATA of a prior MX query.

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jul 2014 15:18:19 +0100

Paul Vixie <[email-masked]> wrote:
> MX",

No, MTAs do not look up MX records for MX targets.

> [". AAAA",] and ". A".

But they might do these lookups, yes.

If this is a worry for the root server operators (but I thought they had
said in the past that it doesn't pose a problem) then the draft could
specify a canonical address-less domain lower down the hierarchy, e.g.
empty.as112.arpa (making use of the AS112 DNAME proposal).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Plymouth: South 4 or 5, becoming variable 3 or 4. Slight or moderate. Rain or
thundery showers. Good, occasionally poor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 18 Jul 2014 10:36:12 -0400

On Jul 18, 2014, at 10:18 AM, Tony Finch <[email-masked]> wrote:

> -

Many years ago Joe Abley and I suggested to create a special name for exactly this purpose
a name that was guaranteed to never exist in the DNS thus the first lookup 
would always return NXDOMAIN thus the A+AAAA lookups would never take place. 
http://tools.ietf.org/html/draft-jabley-sink-arpa-03

	Olafur

---

From: "John Levine" <[email-masked]>
Date: 18 Jul 2014 14:52:37 -0000

>http://tools.ietf.org/html/draft-jabley-sink-arpa-03

While I don't think it's relevant for this application, isn't that
what RFC 6761 defines "invalid" to be?

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Fri, 18 Jul 2014 08:06:34 -0700 (PDT)

> Postfix does the same if you use the reject_unknown_sender_domain option.

FWIW, the equivalent option in the Oracle MTA is called mailfromdnsverify.

> because you would not be able to send a delivery failure report.

Yep. I believe setting this option is fairly common.

				Ned

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 18 Jul 2014 11:21:21 -0400

> what RFC 6761 defines "invalid" to be?

John,

I think it would be great to have this document use “no-mail.invalid.” as the domain name rather
than “.” in the MX record i.e. 
	foo.bar.example MX  0 no-mail.invalid. 

But this is just a question of preference and installed base. 

	Olafur

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jul 2014 17:00:22 +0100

Olafur Gudmundsson <[email-masked]> wrote:
>
> I think it would be great to have this document use “no-mail.invalid.”
> as the domain name rather than “.” in the MX record

I don't think this would help. It would be different from what existing
code recognizes and it would not divert the unwanted A+AAAA queries away
from the root name servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: West or southwest 4 or 5. Slight or moderate. Thundery showers in
north. Good, occasionally poor in north.

---

From: "Mark Delany" <[email-masked]>
Date: 18 Jul 2014 16:53:07 +0000

> I think it would be great to have this document use ?no-mail.invalid.? as the domain name rather
> than ?.? in the MX record i.e. 

The aspirations of this document were far more modest than people seem
to think.

The original intent was to merely document a relatively standard
operating procedure that mail admins routinely deploying. Up to that
point it was trade-craft that sometimes surprised and confused new
mail admins. We wanted to reduce that surprise and confusion. Nothing
more.

There was no original intent to try and change the practice nor to
pass judgment on it. It was deemed that that would be covered by some
future activity if warranted. Maybe "NULLMX considered harmful" if
enough IETF wonks were keen on an admonition or driving an
alternative.

It's been nearly ten years since the original draft was posted, and it
has travelled just about the full length of the IETF digestive
tract. I can readily understand why the original goal may no longer be
apparent.

Importantly, in the intervening decade there has been zero evidence of
sufficient energy to pursue alternatives, yet alone pursue them to
completion. And of course the practice has become far more entrenched
since then.

I encourage folk to consider the doc in that context if they can.

Mark.

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2014 14:35:40 -0400

(copying John Levine given his recent summary on the IETF list
as well as his co-author role)

--On Friday, July 18, 2014 10:36 -0400 Olafur Gudmundsson
<[email-masked]> wrote:

>> If this is a worry for the root server operators (but I
>> thought they had said in the past that it doesn't pose a
>> problem) then the draft could specify a canonical
>> address-less domain lower down the hierarchy, e.g.

> Many years ago Joe Abley and I suggested to create a special
> name for exactly this purpose a name that was guaranteed to
> never exist in the DNS thus the first lookup  would always
> return NXDOMAIN thus the A+AAAA lookups would never take
> place.  http://tools.ietf.org/html/draft-jabley-sink-arpa-03

One more general observation and then I'm going to stop and
leave this part of the issue to you folks.   I believe there is
fairly general (if still a bit "rough") consensus in the email
community that having some clear, DNS-based, way for a system to
indicate that it does not accept email.    Long ago, there was
some hope that WKS records would solve that problem (and others
like it), but we know how that worked out.

Today's problem, IMO, is that, while there is little debate
about "DNS-based solution", or even "DNS-based solution
involving something special in the relevant MX record", I
haven't seen a careful analysis by DBS experts on which of
several DNS approaches have the least bad operational
properties.  If a particular SMTP implementation is aware of and
follows the spec, almost any consensus indicator that doesn't
conflict with other things should be fine -- ".", "*******", a
special name in example.com or example.net, the proposal above,
or something else, because there will be a string compare within
the SMTP server and no lookups will be done.  Since SMTP
prohibits non-ASCII domain names, one might even consider
something Like "фиктивный.example.com" or
"虚假.example.com" (literally, not as IDNA A-labels) which
would cause many SMTP servers to do something nasty that does
not involve the DNS.   

DATA containing "." has the advantage of already being deployed,
so anything else has to offer enough marginal value to overcome
the assumptions that go with existing practice.  But, modulo
that issue, I don't think the SMTP community really cares what
the string is as long as there is a string and a mechanism
(Tony and others have said as much).

The only issue that is, IMO, really important is with
side-effects or damage caused by SMTP implementations that do
not know about the convention or conform to the spec.  They will
certainly do lookups; how far they will get and whether they
will requeue and try again depends somewhat on the string chosen
and, modulo the observation about non-ASCII bogus strings, that
is your area of expertise and not mine (or that of the AppsAWG).

Given that the IETF used to pride itself on the application and
quality of cross-area review, I think it is desirable and
appropriate that the DNS community generally, and DNSOP in
particular, weigh in on the string.  I'd be happiest, and I'm
confident that John L would be too, if the answer was any of 

 * Just fine, "." is no problem
 * Ok, "." isn't likely to cause enough of an incremental
	problem to be worth worrying about.
 * We really wish you had asked ten years ago, but don't
	see "." as causing enough of an incremental problem to
	be worth the difficulties associated with getting
	existing implementations to change their ways.

But, again in the spirit of cross-area review, I'd really like
it --and, as someone who periodically plays email expert on
television, be a lot more comfortable-- if DNSOP had enough of a
discussion to advise on this.  I would hope that, if the advice
were "use a different string, preferable <whatever>, because..."
the IESG and the advocates of "no mail received here" indicator
MXs would pay careful attention.

And I'd like to see the spec reflect the analysis, if only in an
appendix, which may require someone on the DNSOP list to help
John L with text.  But that is, as always, secondary to getting
the spec, protocol, and operational issues right.

    john

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2014 14:59:40 -0400

> haven't seen a careful analysis by DNS experts on which of
> properties.

But, John, this is the one that's implemented in many popular MTAs, has 
been in daily use for the better part of a decade, and has no observed 
issues at all that I ever heard of.  No doubt it sends some traffic to the 
root servers, but have any root server surveys ever even mentioned A or 
AAAA query traffic to "." ?

I can sorta kinda see not wanting to bless it in an RFC, but if we tell 
people to do something different, we'll just look ever more out of touch 
and they'll ignore us.  Again.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jul 2014 20:39:06 +0100

John C Klensin <[email-masked]> wrote:
>
> If a particular SMTP implementation is aware of and follows the spec,
> almost any consensus indicator that doesn't conflict with other things
> should be fine --

There are actually more constraints than you imply in your message.

> "."

Has the advantage of being implemented and deployed. Has the disadvantage
of directing useless queries to the root name servers from MTAs that do
not understand null MX records.

> "*******"

MX target names should obey the LDH host name rules. You won't be able to
enter this target into many DNS admin tools since they enforce LDH syntax.
Some nameservers (e.g. BIND) will by default refuse to load a zone with
a non-hostname MX target.

This loses the advantages of a "." target and fails to keep useless
queries away from the root name servers.

> a special name in example.com or example.net,

These domains are reserved for use in examples, not for production
purposes. Are their name servers scaled up enough to handle stray
queries from MTAs that don't understand null MX records?

This question applies to any non-"." target. The reason I suggested using
AS112 was because it is designed for sinking unwanted queries that should
not have leaked out in the first place. But I still prefer to stick with
".".

> Since SMTP prohibits non-ASCII domain names, one might even consider
> something Like "фиктивный.example.com" or "虚假.example.com" (literally,
> not as IDNA A-labels) which would cause many SMTP servers to do
> something nasty that does not involve the DNS.

You are muddling up the IDNA layers here. The MX target comes from the DNS
so if you try to put an IDNA name there it has to be encoded as an A-label
before you put it in the DNS. If you try hard you can put un-encoded UTF-8
in the DNS, but then it would violate the hostname rules in a similar way
to "*******".

It is likely that there are MTAs which do not check that MX targets
actually obey hostname syntax, so this kind of hack is not going to
reliably suppress lookups.

> They will certainly do lookups; how far they will get and whether they

I think it depends more on the MTA's and/or postmaster's attitude to DNS
misconfiguration. Some are quicker to permfail than others.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Irish Sea: South or southeast 4 or 5, becoming variable 3 or 4. Moderate
becoming slight. Rain or thundery showers, fog patches. Moderate or good,
occasionally very poor.

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2014 16:56:37 -0400

--On Friday, July 18, 2014 14:59 -0400 John R Levine
<[email-masked]> wrote:

> But, John, this is the one that's implemented in many popular
> MTAs, has been in daily use for the better part of a decade,
> and has no observed issues at all that I ever heard of.  No
> doubt it sends some traffic to the root servers, but have any
> root server surveys ever even mentioned A or AAAA query
> traffic to "." ?

If you head read all of my note, you would have noticed that I
expressed a strong preference for staying with "MX ." unless
there were compelling reasons for doing something else.
"Compelling" is a pretty high bar, but I think we need to ask
and then listen.  Also see below.

As to "no observed issues" and indications of support in the
many popular MTAs you have cited elsewhere, I think counting
SMTP implementations is essentially bogus for reasons discussed
(and claims made) in another thread on the IETF list.  For those
with the patience for the analysis, see [1] below.

More relevant, I think, is that the deployment scale for this
convention has nothing to do with how many SMTP servers
implement it -- whether they do by string matching (also see
below) or by giving a "just stop here" interpretation to certain
types of DNS responses to lookup of MS DATA field contents.  If
no one created an "MX ." entry, then the number or types of
servers who were prepared to deal with one in a special way
would be completely irrelevant and the number of queries to the
root would be zero.  Now we both know that there are a bunch of
"MX ." records out there.  I assume the number is not very large
compared to the total number of nodes in the DNS that own
address records or even that number less the number of nodes who
have MX records that point to SMTP servers.  But the load on the
root as the result of this convention (whether "approved" by the
IETF or not) is, unless my brain is completely not working
today, dependent on how often such records are encountered less
the number of systems that trap the "." convention locally.  If
the reason for asking for IETF approval is to encourage more
nodes to be associated with these records (otherwise, you
presumably wouldn't be looking for standards track) then more
"MX ." entries are likely to result in more DNS queries -- how
many more is, I believe, anyone's guess although I discuss some
parameters below.

Part of the issue here is an SMTP subtlety (or perhaps an RFC
5321 glitch).  Your spec says (Section 3) "The DNS root is not a
valid host name, so a NULL MX record can not be confused with an
ordinary MX record."  That is clearly true.  But, while an SMTP
implementation could invoke the "operational necessity"
provision of 5321 and make a string comparison check rather than
sending a query to the root, SMTP does not require that the DATA
associated with an MX record pass SMTP tests of "valid host
name" (in SMTP a rather restrictive bit of local syntax); it
basically requires that whatever is out there be looked up, with
validity (getting back an address record) depending on what the
DNS has to say (see 5321 Section 5.1)

So, again with the stipulation that I may still not fully
understand the issues here, I'd look, not at numbers of SMTP
server implementations, or even the amount of traffic they might
carry, but the number of MX RRs with "." in the DATA.  I'd
assume that number would grow significantly and asymptotically
after this specification is approved and more operators install
the records and then with the growth in the Internet (or the
DNS).  The actual number of queries would depend on the subset
of those nodes that were hit, either intentionally or by
mistake.  I don't think we have any way to estimate that.   In
any event, if one believes in Internet growth and that "don't
send me mail" MX records are a good idea, there will be a lot
more of them in the future, maybe enough to justify a change now
if one is otherwise appropriate (or maybe not).

My apologies for not thinking of it sooner but, if I were
worried about DNS root server impacts (email messaging with
mistakes about domains may be such a small percentage of traffic
to not count) or even unnecessary DNS traffic minimization more
generally, I'd recommend that this new specification explicitly
update Section 5.1 of RFC 5321 to require that DNS servers make
a string-comparison test against "." (or whatever the string
turns out to be) and stop if it is found rather than doing DNS
lookups on whatever is in the data field.  As an alternative,
5321 could be updated to require checking the contents of MX
DATA against the SMTP mailbox domain rules.  Neither would
affect anything that exists today that is reasonable, but they
would move that check from an optimization that may not be
obvious from the current spec (and that requires invoking an
exception rule to be SMTP-conforming) to an explicit
requirement.   Server implementers who haven't heard of this
spec would still invoke the DNS, but, as servers are upgraded,
it would put something of a damper on query growth.

> I can sorta kinda see not wanting to bless it in an RFC, but
> if we tell people to do something different, we'll just look
> ever more out of touch and they'll ignore us.  Again.

<rant>
To the contrary, I think the problem here (if there is one) is
that these types of ideas are being invented, specified through
formal or informal private discussions, deployed, and then
brought to the IETF for standardization.  Had this been brought
to the IETF and gotten the kind of review it is getting now
(including, in this case, a review by DNS folks that probably
would not have occurred in private discussions among email
people) before it was widely deployed, we could have had a
discussion about choices of strings, modifications or
clarifications to SMTP, etc., before the community reached the
point that a proposed change would have to be really strongly
justified in terms of its advantages before anyone would pay
attention.  That is, IMO, where the traditional IETF way of
doing things by moving the _designs_ through cross area review
and consensus processes adds value.  If we are at the point
where the best way to get work done is to prepare a
specification "outside", among enthusiasts, and without any
opportunity for cross-area and skeptical participant review, get
it deployed, and then hand it off to the IETF with statements
like "if we change this, they will ignore us. Again." --even or
especially when that is true-- we might as well hand all of our
standardization work off to ISO/IEC JTC1.  They, I believe, can
do an editorial review and wield a rubber stamp more efficiently
than we can.   That should be fine as long as long as there is
no expectation that they will do a competent engineering review.
And it might leave more time for the IETF to do careful
engineering reviews when that is actually useful.   I guess I
should consider saying that at the plenary.  :-(  </rant>

That said, the developers of most of the SMTP servers you cite
are our friends and pay careful attention to our work.  Several
are even active IETF participants.  If we have a really
persuasive reason why a string change is needed --and it would
have to be both really persuasive and well-documented-- I think
experience indicates that they would adapt, even if they
continued supporting "." (however they do that) forever.

  best,
    john

[1] I vaguely remember a parallel ruckus on the IETF list in the
last week or three where something has been justified because a
number of providers, who are claimed to account for a really
large percentage of the email in the world, like it.  To the
best of my (admittedly limited) knowledge, none of those
providers are running unmodified versions of any of the servers
you cited.  Add all of the corporate/industrial systems that are
running Exchange to the list and there is plausible reason to
assume that an even larger fraction of total email traffic is
not now going through systems that we know are using this
convention.  

First, if one or more of those existing implementations are
making explicit checks for "." in the DATA, they are immediately
irrelevant from a DNS standpoint: no queries are generated to
the root servers unless an implementation blindly picks the MX
DATA up and tries to obtain an address record and take action on
"no record of that QTYPE" failures.   As mentioned above, SMTP
does not require that pre-lookup check.   You may know which of
those implementations do that.  I don't.

However, assuming that every one of them queries the root and
with the understanding that trying to use estimates about total
message traffic as a surrogate for the number of messages that
are likely to encounter non-mail-receiving domains is pretty
dubious, the argument that the community has to live with (and
maybe tune) DMARC because it dominates traffic (what was it,
63%), plus Exchange (maybe another 10%) gets turned around and
into a claim that the servers you are talking about account for,
at most, only 27% of message traffic.   Could that be ok and
getting to 100% be a problem... maybe.  I'm not competent to
judge.

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2014 17:09:59 -0400

--On Friday, July 18, 2014 20:39 +0100 Tony Finch <[email-masked]>
wrote:

>> If a particular SMTP implementation is aware of and follows
>> the spec, almost any consensus indicator that doesn't
>> conflict with other things should be fine --
> 

Yes, almost certainly.

>> "."
> 
> Has the advantage of being implemented and deployed. Has the
> disadvantage of directing useless queries to the root name
> servers from MTAs that do not understand null MX records.
> 
>> "*******"
> 
> MX target names should obey the LDH host name rules.

I completely agree, but SMTP imposes no such requirement.

> You won't
> be able to enter this target into many DNS admin tools since
> they enforce LDH syntax. Some nameservers (e.g. BIND) will by
> default refuse to load a zone with a non-hostname MX target.

Does that imply that this spec should contain a warning that
loading one of these "null MX" records may require a
configuration change in one's nameserver?   Just asking.

> This loses the advantages of a "." target and fails to keep
> useless queries away from the root name servers.
> 
> These domains are reserved for use in examples, not for
> production purposes. Are their name servers scaled up enough
> to handle stray queries from MTAs that don't understand null
> MX records?

Yep.  Sorry for not selecting a better example, but I hope the
point was clear.

> This question applies to any non-"." target. The reason I
> suggested using AS112 was because it is designed for sinking
> unwanted queries that should not have leaked out in the first
> place. But I still prefer to stick with ".".

Ok, thanks for clarifying.
 
>> Since SMTP prohibits non-ASCII domain names, one might even
>> consider something Like "фиктивный.example.com" or

> You are muddling up the IDNA layers here. The MX target comes
> from the DNS so if you try to put an IDNA name there it has to
> be encoded as an A-label before you put it in the DNS. If you
> try hard you can put un-encoded UTF-8 in the DNS, but then it
> would violate the hostname rules in a similar way to "*******".

I'm actually not... and sorry if I wasn't clear.   Because SMTP
doesn't impose any restrictions on what it can pick up from MX
DATA (presumably the only limits are those imposed by 2181) and
knows nothing about IDNA, un-encoded UTF-8 (or, for that matter,
un-encoded UTF16 or something else as long as it is within the
64 byte label limit, is just meaningless trash -- far further up
the "trash" scale than "******".   If an implementation chooses
to apply host name checks (or SMTP mailbox domain name validity
checks) that seems wise to me, but goes beyond what SMTP
requires.

> It is likely that there are MTAs which do not check that MX
> targets actually obey hostname syntax, so this kind of hack is
> not going to reliably suppress lookups.

Exactly.  They are different examples of guaranteed bogus
strings; they don't help a bit with the query problem.   If we
really want help with the query problem, we need to update SMTP
(see previous over-long note to DNSOP, which I'll forward to you
under separate cover.

>> They will certainly do lookups; how far they will get and
>> whether they will requeue and try again depends somewhat on
>> the string chosen
> 
> I think it depends more on the MTA's and/or postmaster's
> attitude to DNS misconfiguration. Some are quicker to permfail
> than others.

Yep,  And that is independent of whether we agree about what
constitutes "DNS misconfiguration".  Had you said
"misconfiguration, abuse, or stupidity", we'd probably agree.
:-)

    john

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jul 2014 22:39:34 +0100

> I completely agree, but SMTP imposes no such requirement.

RFC 974 specifies that the target of an MX record is a host name.

> > You won't be able to enter [*******] into many DNS admin tools since
> > they enforce LDH syntax. Some nameservers (e.g. BIND) will by default
> > refuse to load a zone with a non-hostname MX target.
>
> configuration change in one's nameserver?

No, because "." doesn't violate LDH syntax. (What admin GUIs do is another
matter...)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames: Mainly southeast 4 or 5, increasing 6 at times. Slight or
moderate. Thundery showers. Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jul 2014 23:08:03 +0100

John C Klensin <[email-masked]> wrote:

> brought to the IETF for standardization.

The null MX record is simply re-using the existing logic for null SRV
records, so the design already has IETF approval.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
East Sole, Lundy, Fastnet: Southerly becoming variable 3 or 4. Slight or
moderate. Thundery showers. Good, occasionally poor.

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2014 19:32:48 -0400

(Warning to DNSOP and IESG -- this response is going to descend
quickly into SMTP esoterica and is probably safe to ignore from
a DNS perspective)

> RFC 974 specifies that the target of an MX record is a host

And so?  RFC 2821 obsoleted 974.  As far as I can tell, it says
nothing at all about the DATA field in an MX record, leaving
pulling that information out and looking it up in the DNS to be
inferred from context and a parenthetical comment "(perhaps
taken from the preferred MX record)".  It does use the term
"host addresses" and "destination host", but in a too-informal
context to assume that people would infer "host name" (aside:
whatever that means) in the DNS sense.  After 14+ years, I no
longer remember and cannot reconstruct whether that was a DRUMS
screwup or mine although the WG is ultimately responsible for
not reviewing carefully enough.

When RFC 5321 was done, we obviously knew there was a problem
with the 2821 text because its text improves on the situation.
The pre-5321 change log doesn't say much that sheds light on the
change, other than saying that the description of MX handing
was changed in -10 (one of several post-Last-Call versions).
The relevant section is more clear and it does explicitly say
"the data field of that response MUST contain a domain name.
That domain name, when queried, MUST return at least one address
record (e.g., A or AAAA RR)".  But that is it: "domain name".
One can read that as an invocation of the discussion in Section
2.3.5 but that isn't the only possible reading.  The section
invokes 1035 and "a sequence of letters, digits, and hyphens
drawn from the ASCII character set."   The following sentence
reads "Domain names are used as names of hosts and of other
entities in the domain name hierarchy." so, while 2.3.5 (if one
believes that the text in 5.1 invokes it) requires LDH, it does
not require a "host name".    If one doesn't believe that 2.3,5
is invoked, then a domain name is presumably just an FQDN
conforming to 1034/1035 as interpreted by 2181).  There is,
fwiw, some additional test in 2.3.5 that further muddies the
waters. 

That is definitely not a good example of clarity or precision.
Mea culpa, with or without comments about quality of review.  I
have tightened things up in the 5321bis editing copy (yes, there
is such a thing).

> No, because "." doesn't violate LDH syntax. (What admin GUIs
> do is another matter...)

Those admin GUIs or text input converters were what I was
concerned about (should have said "nameserver configuration
interface" or words to that effect).  Your call (and John L.'s).

    john

---

From: Mark Andrews <[email-masked]>
Date: Sat, 19 Jul 2014 10:40:09 +1000

In message <[email-masked]>, Tony F
> queries away from the root name servers.

"." is a place holder exception.  Below is a minimal zone with a MX with all
the domains set to ".".  Named will load "MX 0 ." fine.  "." prevents lots
of the internal checks at load time from triggering.

% named-checkzone zone zone
zone:1: no TTL specified; using SOA MINTTL instead
zone zone/IN: loaded serial 0
OK
% cat zone
@ SOA . . 0 0 0 0 0
@ NS .
@ MX 0 .
% 

"MX 0 ." is also consistent with "SRV 0 0 0 ." which is documented.

"no-mail.invalid" however will elicit a warning / failure depending
upon what the error level is set to.  Named-checkzone looks up every
MX target and check for A or AAAA records with the exception of
".".  It also checks that they are syntactically valid hostnames.
It also tries to determine if a IPv4 address has been used instead
of a hostname by mistake.

% named-checkzone zone zone
zone:1: no TTL specified; using SOA MINTTL instead
zone zone/IN: zone/MX 'no-mail.invalid' (out of zone) has no addresses records (A or AAAA)
zone zone/IN: loaded serial 0
OK
% cat zone
@ SOA . . 0 0 0 0 0
@ NS .
@ MX 0 no-mail.invalid.
% 

"." is a really good exception marker.  It is also the minimal
exception marker we can have.

> > something Like "=D1=84=D0=B8=D0=BA=D1=82=D0=B8=D0=B2=D0=BD=D1=8B=D0=B9.ex=
> ample.com" or "=E8=99=9A=E5=81=87.example.com" (literally,
> --=20
> --1870869256-999632820-1405712346=:28941
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --1870869256-999632820-1405712346=:28941--
>

---

From: Mark Andrews <[email-masked]>
Date: Sat, 19 Jul 2014 10:46:38 +1000

The target us a hostname (RFC 1035).

3.3.9. MX RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                  PREFERENCE                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   EXCHANGE                    /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

PREFERENCE      A 16 bit integer which specifies the preference given to
                this RR among others at the same owner.  Lower values
                are preferred.

EXCHANGE        A <domain-name> which specifies a host willing to act as
                a mail exchange for the owner name.

In message <[email-masked]>, John C Klensin writes

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Jul 2014 08:27:01 -0400

> "MX 0 ." is also consistent with "SRV 0 0 0 ." which is documented.

Right.  As Tony Finch has also noted.

The specific citation is:

   RFC 2782:

>    Target
...
>         A Target of "." means that the service is decidedly not
>         available at this domain.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Jul 2014 13:59:54 -0700

On 7/17/2014 10:39 AM, John C Klensin wrote:
> 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
> 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.

> accurate and accurate about the protocols it cites.

You do not clearly indicate any historical inaccuracy at issue.

> 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.

> 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.

> to define terminology without which the document cannot be

So, you are suggesting that RFC 5598 be a normative reference here?

> in the envelope with nothing following it, and that would be bad

So you are suggesting:

  empty RFC5321.MailFrom address
  ->
  null ("<>") reverse-path, per 3.6.3 and 6.1 of RFC 5321

> 	reverse-path) SHOULD be sent with a valid, non-null

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...

> doesn't help with readability but the problem exists even

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.

> referenced from this one.

How would that be better than what is in the current draft?

d/

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Jul 2014 17:27:59 -0500

> >   <draft-ietf-appsawg-nullmx-05.txt> as Proposed Standard

When I first saw this and your reply I thought "what the heck is he
talking about, it's so obviously a good idea".  Then I read sections 4.3
and 5.  Now I join the objection chorus.

> non-delivery.    [...]

I think what you're objecting to is the section 4.3 and related text
that conflates "does not accept e-mail" with "does not send e-mail".  If
so I agree.  The two assertions *must* be separable!  And preferably the
two assertions should be separate both, in terms of mechanism and
specification.

Assuming this conflation were fixed or the "does not send e-mail" text
removed, nothing in the remainder of the draft prevents notifications
for non-deliveries.  Indeed, the "does not accept e-mail" assertion
[greatly] optimizes the case where the target domain does not accept
incoming e-mail -- a very desirable feature, and one worth standardizing
without any relation to "does not send e-mail" assertions.

I especially reject the first sentence of the third paragraph of section
4.3: regardless of the truth of that statement, it is insufficient to
draw the inference "does not accept e-mail implies does not send
e-mail".

> First, two issues of terminology:

+1, but I think this should all be fixed by removing section 4.3 and any
remnant of the conflation of "does not accept" with "does not send"
e-mail.  That is my preferred resolution.

I strongly recommend splitting this into two I-Ds, or at the very least
section 4.3 and related text into a top-level section.  The "does not
send e-mail" assertion *must not* be the same as the "does not accept
e-mail".

Nico
--

---

From: Pete Resnick <[email-masked]>
Date: Tue, 22 Jul 2014 09:27:43 -0400

This message is admittedly 4 days too late. In my opinion, we area 
directors got caught out not paying attention and did not act to address 
problematic behavior on this list in a reasonable amount of time, and 
haven't been doing so for some time. The IESG is taking this ongoing 
behavior seriously, and you'll see some discussion in the next few days 
about how we intend to address it. But this particular thread had some 
serious misbehavior, that behavior came from senior members of the 
community, and it needs to be called out in particular.[1]

Of course we need to learn to focus our review comments and discussions 
at Last Call, we need to make concrete and constructive suggestions for 
changes (preferably supplying text), and when we respond to reviews we 
should filter superfluous commentary and solicit specific 
recommendations where they were missing. But this is general advice and 
not an issue of the kind of misconduct I'm referring to. The problem in 
this thread came when, instead of constructively responding to the 
initial posting and simply filtering out non-constructive comments, the 
responses and continuing conversation served to *raise* the temperature 
instead of lowering it. Engaging in sarcasm, belittling of comments, 
baiting rhetorical questions, and aggressive (whether directly or 
passive-aggressive) commentary drives some folks away from the 
discussion (or participation in general), causes other folks to think 
that it's acceptable behavior, and causes further discussion to degrade.

Luckily this thread seems to have converged, and I think it would be 
terribly unproductive to argue about the merits and demerits of this 
particular thread on this list, but this kind of behavior needs to stop. 
That requires everyone to commit to trying harder to engage civilly, and 
to not tolerate misbehavior. That doesn't mean that you should take it 
upon yourself to police and control other people's behavior; that only 
serves to compound the problem. But if discussions are not being 
appropriately moderated, you should bring that to the attention of the 
ADs; we are committing to making sure that things improve.

pr

[1] You may react to this by saying, "There has been far worse behavior 
on this list in recent years. Why pick on this particular thread?" The 
answer is, we have to start somewhere, and it happens that several 
people, including some of the participants in this thread, made specific 
complaints about his particular case.

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 23 Jul 2014 09:39:53 -0400

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Jul 2014 14:54:14 +0100

Kevin Darcy <[email-masked]> wrote:

> 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.

A target of "." causes an immediate permanent failure, whereas a tagret
that resolves to 0.0.0.0 is likely to cause retries and eventual timeouts.

> The null address does, after all, mean "no service offered here".

No, it means "this host" - see RFC 3330.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, North German Bight: Northeast 3 or 4. Smooth or slight. Fair. Good.

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2014 14:14:55 -0000

>that resolves to 0.0.0.0 is likely to cause retries and eventual timeouts.

In practice, A records of 0.0.0.0 cause mail loops, and I have the logs
to show it.  It's a really bad idea.

The version of null MX in the draft has been in wide use since 2006.
If anyone wants to do something different, the proposal needs to
explain why it is so much better than the existing practice that all
of the existing implementations that already work would be willing to
change their code.

R's,
John

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 23 Jul 2014 10:24:12 -0400

Well OK, so it's a semi-dumb question. But if we're going to assign 
"magic meaning" to something, why not assign "magic meaning" to the null 
address *specifically*in*the*context*of*SMTP*message*delivery*strategy*, 
i.e. auto-fail messages destined for the null address and never retry them?

To nitpick your standards point about the null address, Section 2.5.2 of 
RFC 4291 says that the IPv6 null address (which it idiomatically calls 
"the unspecified address")

"must not be used as the destination address of IPv6 packets or in IPv6 
Routing headers"

which effectively amounts to "no service here". Can't get there.

I haven't gone back to see if the IPv4 null address has been similarly 
clarified/redefined, because, who still uses IPv4 anyway? :-)

                                             - Kevin

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Jul 2014 17:16:40 +0100

Kevin Darcy <[email-masked]> wrote:

> But if we're going to assign "magic meaning" to something, why not
> assign "magic meaning" to the null address
> *specifically*in*the*context*of*SMTP*message*delivery*strategy*, i.e.
> auto-fail messages destined for the null address and never retry them?

Because that will have horrible fallout for existing software that does
not undestand the magic meaning.

@ MX 0 . already has the correct semantics; the only magic in the nullmx
spec is to suppress the A and AAAA lookups because they will always fail.

> clarified/redefined, because, who still uses IPv4 anyway? :-)

Yes, 0.0.0.0 is only for use as a source address.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South-east Iceland: Variable 3 or 4, becoming southeasterly 5 or 6 for a time
in east. Slight or moderate. Fog patches, occasional rain. Moderate or good,
occasionally very poor.

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 23 Jul 2014 14:36:30 -0400

OK, fair enough. Just as long as we understand and properly record the 
design decision that was made here:

I.e. we're more afraid of the negative consequences of software/OSes 
that don't treat null addresses reasonably (i.e. pointless/doomed 
retries, possible self-looping) than we are of the negative consequences 
of software that is slow or defective in their adoption of the new magic 
meaning of root-name MX targets (i.e. pointless/doomed A/AAAA queries of 
the root name).

                                                 - Kevin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Jul 2014 12:00:34 +1000

> if only load-balancer vendors could wrap their tiny minds around that 

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.

---

From: "Mark Delany" <[email-masked]>
Date: 24 Jul 2014 02:41:07 +0000

> ::0) does not? No protocol or code changes required.

And just to be clear, nullmx as proposed does not required any code
changes and never has. It's simply recognizing a (to me at least)
serendipitous confluence of existing attributes of DNS and SMTP.

No new protocols are being invented and no deviation from those two
standards is being suggested.

Remember, considerate receivers have been adding this MX to their
zones for many years and senders, whether they know it or not, having
been automatically reaping the benefits as a consequence.

This is about as close as it gets to a free lunch on the Internet.

Mark.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 24 Jul 2014 12:27:00 -0400

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Jul 2014 10:02:06 +1000

> obvious optimization to me.

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

---

From: "Mark Delany" <[email-masked]>
Date: 25 Jul 2014 03:10:19 +0000

On 24Jul14, Kevin Darcy allegedly wrote:
> tempfail to a permfail?

Most SMTP clients use a DNS cache so they have no idea what the
original TTL is.

Even if they could see the auth TTL you'd have to worry about domains
that just happen to have very large TTLs in place today for whatever
reason. How do you differentiate those domains?

As far as standardizing such an idea, I'd hazard a guess that the IETF
would not look kindly on encoding semantics into TTL values. Your
rationale for this approach would need to be pretty compelling.

> I've never written an MTA, but it seems like an 

It's surprising how hard it is to get the TTL out of most DNS client
libraries. None of the gethostby* family return it. Even fancy
libraries like c-ares are hit and miss with making the TTL available
for different RR types.

And of course the whole thing implies changing every SMTP client on
the planet to recognize these large TTLs. That's a bit of work.

All in all it's hard to see what this approach achieves compared to
nullmx which works today with no code changes and does not require any
special interpretation of DNS data.

Mark.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Jul 2014 13:20:29 +1000

In message <[email-masked]>, "Mark Delany"
> special interpretation of DNS data.

	0.0.0.0 and :: are orthognal to MX 0 .

	One means "I am a host, I exist, but I don't know my/have
	a address" presumably because it is offline, the other means
	"There is no SMTP service for this domain".  One is temp
	fail for SMTP, the other is a permanent fail.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 25 Jul 2014 13:18:05 -0400

Well, I think I'm being misunderstood here. Allow me to try and clarify.

A) SMTP software -- all software, really -- should have a general 
optimization of "don't try things that are doomed to failure"
B) As a specific instance of that general optimization, there's no point 
in retrying a message that failed because of what was returned from DNS, 
if the exact same records are still cached from the earlier lookup. 
(Insanity is sometimes defined as doing the same thing, in the same 
circumstances, and expecting a different result).
C) Does this imply that SMTP software should look at TTLs? Sure. Is this 
harder to do with some APIs than others? Certainly. It is the nature of 
optimizations that they are not *perfect*. Only that the help a lot, to 
minimize wasted effort and/or resources
D) No "special semantics" are being applied to TTLs here. Just the 
(obvious, definitional) fact that the TTL value controls cache 
expiration, together with the realization that there's no point in 
retrying a message if the contents of your name-resolution cache are 
going to doom your attempt
E) Putting all of this together: domain owners who choose not to provide 
SMTP service could point their MX to a name, of their choosing, that 
resolves to a null address, and with a sufficiently-high TTL, such that 
SMTP clients obeying the optimization identified above, will auto-fail 
the message (tempfail promoted to permfail) if the DNS-record expiration 
time would occur after the client's queue-expiration time. Bonus points 
awarded for recognizing the special nature of the null address and 
giving a nice friendly error message back to the sender to the effect 
that mail service is not available for the domain.

I remain skeptical that the methodology in the draft, as written, 
requires no code changes, since I just performed a private experiment 
with a recent version of sendmail, and delivery failed in a 
spectacularly ugly way that made it appear much more like a bad .cf than 
"no mail accepted for this domain". But, I'll spare everyone the gory 
details of that experiment, and its aftermath, if someone can give me an 
example (send privately if you wish) of a domain on the Internet with 
this "null MX" setup, and I'll talk to our gateway folks to see if it 
fails in similarly ugly ways, at recent or latest code versions of our 
gateway software. (Yes, I know it was said earlier in the message thread 
that there have been no negative consequences of this "null MX" 
methodology after years of deployment, but I'm going to be from Missouri 
here -- "show me").

As a minor editorial nit, the draft refers to "null MX" being "an 
ordinary MX record" in the Security Considerations, after Section 3 
already proclaimed "a NULL MX
record can not be confused with an ordinary MX record". So it is 
"ordinary" or isn't it? Maybe different adjectives should be used...

                         - Kevin

---

From: Tony Finch <[email-masked]>
Date: Fri, 25 Jul 2014 18:32:56 +0100

Kevin Darcy <[email-masked]> wrote:

> if someone can give me an example (send privately if you wish) of a
> domain on the Internet with this "null MX" setup

Here's a few our servers encountered today:

agandm.com
dur.net
eay.com
fnjr.com
jolmail.com
lfdf.com
lki.org
lllk.com
missionnews.com
ns1.com
oeh.org
qths.com
rthc.com
samueldumoulin.com
sandradance.com
senders.org
sexnow.com
wzr.net
zcij.com

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle: Easterly veering southeasterly 3 or 4, occasionally 5 in south.
Slight, occasionally moderate in south. Fog banks. Moderate or good,
occasionally very poor.

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Jul 2014 18:36:28 -0400

On 7/25/2014 1:18 PM, Kevin Darcy wrote:>
> spectacularly ugly way that made it appear much more like a bad .cf
> than "no mail accepted for this domain". But, I'll spare everyone the
> gory details of that experiment, and its aftermath, if someone can
> give me an example (send privately if you wish) of a domain on the
> Internet with this "null MX" setup, and I'll talk to our gateway folks
> to see if it fails in similarly ugly ways, at recent or latest code
> versions of our gateway software. (Yes, I know it was said earlier in
> the message thread that there have been no negative consequences of
> this "null MX" methodology after years of deployment, but I'm going to
> be from Missouri here -- "show me").

I agree with you that code changes are needed, at least for our package.

A published NULL MX does not reduced the number of MTA retries in our 
implementation and thats because there are high false positives so the 
full attempts are tried until exhausted.

We will need to tweak the code or the retry frequency table for this 
particular socket error, in this case 10061.   To optimize, we will 
need to specifically look for three conditions:

    MX.Count == 1 and
    MX[0].Preference == 0 and
    MX[0].Exchange == "."

to trump, preempt any call attempt.

-- 
HLS

---

From: Mark Andrews <[email-masked]>
Date: Sat, 26 Jul 2014 08:41:16 +1000

> to trump, preempt any call attempt.
 
Nuke the preference check.  Count and exchange is enough.

---

From: Hector Santos <[email-masked]>
Date: Sun, 27 Jul 2014 14:14:14 -0400

> Nuke the preference check.  Count and exchange is enough.

Hi Mark,

Sure, but its not the true "spec" condition.  As stated in section 3, 
anything else but the three conditions could be programmatically 
extracted to be an "error" some where; an exception, indeterminate 
condition, possible corruption, "not the spec condition," a "how can 
this happen" situation. What does an diligent, high QA conscious coder do?

"Being Specific Is Terrific!"

If the preference can technically be any non-zero value for a No Mail 
Service MX record, then the spec should probably make note of that in 
section 3, otherwise a coder may wonder and add an exception.

    3. MX Resource Records Specifying Null MX

    To indicate that a domain does not accept email, it advertises a
    single MX RR (see [RFC1035], section 3.3.9) with an RDATA section
    consisting of a zero length label, written in master files as ".",
    as the exchange domain, to denote that there  exists no mail
    exchanger for a domain.  The Preference SHOULD be set to zero, but
    implementators SHOULD NOT depend on it being zero for the NULL MX
    to be defined.

Additional comments/nits about the draft:

o Preference vs Priority

An implementation note could be added:

    Implementation note:  Some DNS record UI managers use the term
    "Priority" instead of "Preference."   MX expansion requires a
    sorted mail host order by increasing preference. The mail
    host with lower preferences are tried first. A Higher priority
    value in these UIs does not mean they are tried first.

The DNS management tools I just recently used (Microsoft DNS v5 
Windows GUI manager and Godaddy's web-based DNS manager) to quickly 
explore this used, the term "Priority" instead of the IETF spec 
defined "Preference" term for this MX field name.  The draft has no 
reference to the term "priority" and/or the possible market, 
administration and technical terminology discrepancies.

o No Permanent Blocks Semantics

I think the draft should make a note that permanent blocks should not 
be extracted from an NULL MX records or the final resolution of 
attempts.  The NULL MX condition can quickly change at any time.  It 
is merely (to me, as I can see) an optimizer to short circuit an 
outbound attempt and also test an incoming message return path domain 
readiness for bounces/DSN which is a SMTP required mode of operation.

o Security overstatement

  I think the security section does not need to be talking about SMTP 
being 'inherently insecure."  Whether a site does dynamic checking or 
not of the SMTP session return path is the main thing here.  This 
draft isn't removing any insecurity other than suggesting it is one 
way to detect the "mail hosting service availability" of an email 
domain without the need to actually try/test it.  An optimizer.

In fact, I think its possible that the attempt to define a NULL MX can 
actually "nullify" and learned behaver for a Implicit MX logic where 
there is no record at all. NULL MX is a real record and that can 
trigger different logic than an real NO MX record condition. For 
example, some MTA may have an option:

    [X] NO MX, Try A record ONCE TIME

That was the case for our older version of MTA. The rule was relaxed 
(default OFF) due to the false positives.  So for the modern versions, 
it doesn't matter anymore -- retries are based on the last SOCKET or 
SMTP error condition.

-- 
HLS