Subject: Re: 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: 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...

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

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

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

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

> 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: Sandy Wills <[email-masked]>
Date: Thu, 17 Jul 2014 19:56:48 -0400

> Service Offered MX Record".

As a clear statement of policy, the latter is preferable.

    Those two can easily be construed to mean different things.  The 
former may mean a current temporary condition "Yes we have no email 
service here today, please check back tomorrow".  The latter is clearly 
a policy statement "We don't do no stinking email here".

Sandy Wills
(semi-inactive lurker)

-- 
Unable to locate coffee.
Operator halted.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 18 Jul 2014 01:01:55 +0000

> messages or connections over successful delivery of legitimate

In find nullmx on the contrary far less objectionable than all
other anti-abuse measures.  I just designates non-sending domains,
via a simple low cost mechanism.  It is already reasonably widely
in use even without a formal standard, based on the prior draft
revisions.  There is nothing here that is about silent discard of
mail by remote domains.  The origin domain declares non-sending of
mail and receiving systems are free to reject forgeries.

It is certainly far less damaging than DMARC.

> That is not a strong technical objection and is

Thanks.  The subsequent technical comments are generally sound and
should be addressed.

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

This is likely already practiced, and is clear enough in practice.
Keep in mind that there are no legitimate senders of mail blocked
by nullmx rejection, so the DSN status codes are of little interest
to anyone but the bad guys.

The primary use for nullmx is parked domains.  At previous employer
we configured thousands of parked domains with nullmx RRs.

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Jul 2014 18:06:42 -0700

On 7/17/2014 6:01 PM, Viktor Dukhovni wrote:
> other anti-abuse measures. 

Although it has some utility for anti-abuse, it is not an anti-abuse
mechanism.  It is of more general benefit.

> I just designates non-sending domains,

No, it designates non-/receiving/ domains:

   Abstract:

   "The NULL MX RR formalizes the existing
   mechanism by which a domain announces that it accepts no mail,"

d/

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Jul 2014 22:50:41 -0400

--On Friday, July 18, 2014 01:01 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>> 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.
> 
> This is likely already practiced, and is clear enough in
> practice. Keep in mind that there are no legitimate senders of
> mail blocked by nullmx rejection, so the DSN status codes are
> of little interest to anyone but the bad guys.

In an odd way, your comment above illustrates the reason I think
an extended status code would be useful and why I'm concerned
that this draft might not have received adequately broad review.
If the use of nullmx were confined to parted domains, I would
agree with you and not see a problem.  But the document doesn't
say that -- from reading it, one could get the impression that
it is being recommended for the domain associated with any
system that doesn't expect to receive mail.  That leads into
some of the other cases, including the large mail operator whose
sending and receiving hosts are separate, as discussed earlier
and, e.g., some interesting questions about what happens if,
despite what it says in the document, multiple MX records are
configured only one of which has "." as the data.   In some of
those cases, the cause of rejection might be an operational
configuration error, not an error on the part of the sender.
For such cases (including the examp1e.com one) details status
codes could be a big advantage.

> The primary use for nullmx is parked domains.  At previous
> employer we configured thousands of parked domains with nullmx
> RRs.

I'm not recommending this but, if the documents said "this is
for parked domains, for any other cases, the structure is
outdated and SHOUDL NOT be used except under special
circumstances and with adequate explanation.

     john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Jul 2014 20:09:12 -0700

On 7/17/2014 7:50 PM, John C Klensin wrote:
> for parked domains,

You mean, like www.ietf.org, which is never a legitimate email target
hostname, but is rather easily specified in error?

d/

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Jul 2014 13:26:11 +1000

There are lots of machines which do not have the SMTP port configured
yet have A or AAAA records resulting in a implicit MX record and
week+ long no delivery notifications.

Just about everyone with a outsourced HTTP service needs to be able
to stop MTAs sending to email to the outsourced service.  MUA's
could also lookup the MX RRset and issue a error without talking
to the MSA.

I can remember adding a null SMTP service back in the early 90's
that just 500'd all connection attempts to deal with all the miss
directed email accidently sent to desktop machines that I never
wanted to receive email even if they emitted it.  This was much
better than having to chase down "why didn't xxxx get my email, I
sent it yyy days ago".  The immediate bounce is important and getting
it a close to the sender as possible is important as it reduces the
chance that it will be dropped / missed.

The alternative to this is to remove the implicit MX record
construction from SMTP and make the presence of MX records manditory
for SMTP.  I'm sure there will be many more complaints about doing
that than adding a explict no service record.

As for this along with other explict mx records.  I would say to
ignore this record in the M[TU]A.  Zone checking tools could warn
/ error if this is present.  UPDATE could reject adding records if
there would be this and another record.  Name servers could be
configured to warn / reject zones which have this and other MX
records.

---

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: "John Levine" <[email-masked]>
Date: 18 Jul 2014 04:06:23 -0000

>week+ long no delivery notifications.

Right.  That's exactly, precisely, the problem that null MX is
intended to address.

>construction from SMTP and make the presence of MX records mandatory
>that than adding a explicit no service record.

That would be fine with me, but I hear it's 30 years too late, even for IPv6.

R's,
John

---

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: Ted Lemon <[email-masked]>
Date: Fri, 18 Jul 2014 07:50:28 -0400

> could also lookup the MX RRset and issue a error without talking

I must be missing something here.   You're saying you want me to set up a null MX for all my hosts to prevent someone else's MTA having undeliverable mail sitting in the queue for a week?   Why would I care about your MTA's queue?   Why would this issue even be on my radar?

The second example you give, stopping mail being delivered to the web server, is actually served better by setting up a proper MX that directs the mail to the right server.   Does an HTTP server really care about the occasional SYN to port 25?

I'm not against this draft moving forward, but I find these use cases somewhat puzzling.

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2014 07:58:05 -0400

> You mean, like www.ietf.org, which is never a legitimate email
> target hostname, but is rather easily specified in error?

Dave,

Please see the first part of that sentence, i.e., "I'm not
recommending this".  The note to which I was responding appeared
to me to have the premise "this is mostly for parked domains"
and appeared to reason on that basis.  There is certainly no
doubt that it is useful for the type of parked to which I
believe he was referring, independent of whether one believes
that is the primary use.  I believe that the author of that note
is both competent and sincere and deserved a response on that
same basis.  I was temporarily accepting his premise, following
it to what seemed to be its implications, and suggesting that,
if it were the case, then some things would be different and a
slightly different approach would be in order.

If you find a flaw in that style of reasoning, please explain.

To repeat what I said initially and which I hoped was clear in
the original wording: I have some concerns about this mechanism,
especially when it is used with domains that may appear in
backward-pointing addresses (see Tony Finch's recent note about
the reasons for doing that), I do not oppose its approval ("its"
referring to the mechanism) [1].  However, I think the document
needs work -- particularly in the areas of problematic
terminology (with "NULL MX Resource Record" in the document
title, section title, and elsewhere being an important
illustration), explanation of likely issues and how they should
be handled (with systems with separated sending and receiving
hosts as a case of particular importance), some document
organization issues (e.g., buried terminology definitions and
issues in Security Considerations that really deserve separate
treatment), and so on.

I don't consider any of those issues earthshaking, they just
suggest the draft needs a little work before it is approved.

For the sake of clarity because most of what I've written in the
last few weeks seems, from your remarks, to have been
incomprehensible, the list of items mentioned above are just
examples.  The absence of something from that list that appears
in my original posted review on this draft does not indicate
I've lost interest in it, merely that I did not include it in
the illustrative examples above.

If some part of that is still difficult for you to understand,
please just tell me what it was and I will try to clarify.  My
hope is that we are all working together to improve this (and
other) specifications, rather than trying to accomplish
something (I am disinclined to speculate on what) by
discrediting postings that try to identify issues.

  best,
    john
   
[1] You also questioned my "distasteful" remark on the basis,
IIR, that no one else had said so.  While there have been some
recent trends toward organizing groups to propose or comment on
some actions (trends that I believe are inconsistent with IETF
principles about individual participation, but YMMD), I've never
been aware that one was required to demonstrate support for a
position or comment before making it, especially on an IETF Last
Call.  I had not intended to explain the reason for my distaste
because I think it a distraction from getting this spec to an
appropriate quality level.  However, because your remarks appear
to call for it, I believe (in agreement with what this document
just about says) that this mechanism is a back-door workaround
to requiring MX records for any host that is willing to accept
incoming email.  Such a requirement would be architecturally
reasonable and would permit some nuance that MX records pointing
to the root do not such as allowing address records to be for
empty reverse path notification messages but not normal ones
with usable reverse paths (not saying that would be a good idea,
only mentioning the possibility).  Several WGs and document
review discussions have rejected the approach of imposing that
requirement, probably for good reasons even though we might have
been able to work out a plan for deprecating the fallback with
sufficient notice.   While some of us started writing SMTP
server simulators that would simply generate 5xy replies as soon
as someone tried to open a port 25 connection and installing
them on machines that did not accept mail, there is an apparent
consensus that remedy is inadequate because of the retry
problem.  With one of those solutions rejected and the other
judged inadequate, the current mechanism is a reasonable
candidate for the best approach for dealing with the issues.
That doesn't mean I have to like it or think it is
architecturally elegant.  Hence "distaste".

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Jul 2014 05:08:52 -0700

On 7/18/2014 4:58 AM, John C Klensin wrote:
> I believe (in agreement with what this document
> incoming email. 

It says and implies no such thing.  Nor does it move us towards that.

Suggesting otherwise sounds odd, given that you say you don't object to
the mechanism.

The document formalizes an existing practice.  We sometimes do that in
the IETF.

d/

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jul 2014 13:42:38 +0100

Ted Lemon <[email-masked]> wrote:
>
> I must be missing something here.  You're saying you want me to set up a
> null MX for all my hosts to prevent someone else's MTA having
> undeliverable mail sitting in the queue for a week?  Why would I care
> about your MTA's queue?  Why would this issue even be on my radar?

More likely you want to avoid undeliverable mail on your own mail server
queues, so that you don't get complaints from your users about mail
disappearing.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FitzRoy: Cyclonic 4 or 5, increasing 6 at times. Moderate. Thundery showers.
Good, occasionally poor.

---

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

>I must be missing something here.   You're saying you want me to set up a null MX for all my hosts to
>prevent someone else's MTA having undeliverable mail sitting in the queue for a week?   Why would I care

To get a definitive answer, you'd have to ask some of the many people who already
implement null MX.  In my case, it's partly because my own users mistype names
and the typos happen to be names that resolve in my DNS, and partly because people
write and say "sorry, I wrote to ask where to send your $50,000 check and I just
saw that I mistyped your address a week ago."

>The second example you give, stopping mail being delivered to the web server, is actually served better
>by setting up a proper MX that directs the mail to the right server.   Does an HTTP server really care
>about the occasional SYN to port 25?

Well, OK.  What would be the proper MX for mail sent to [email-masked] ?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Jul 2014 07:45:50 -0700

On 7/18/2014 4:50 AM, Ted Lemon wrote:
> I must be missing something here.   You're saying you want me to set
> up a null MX for all my hosts to prevent someone else's MTA having
> undeliverable mail sitting in the queue for a week?   Why would I
> care about your MTA's queue?   Why would this issue even be on my
> radar?

Well, some operators actually like being good neighbors, especially when
the effort needed is tiny and one-time.

But even if they don't care about that, they might prefer not to have
those guys banging on their servers for days until the message times out.

> The second example you give, stopping mail being delivered to the web
> server, is actually served better by setting up a proper MX that
> directs the mail to the right server.   Does an HTTP server really
> care about the occasional SYN to port 25?

Ahhh.  You haven't heard of the scaling effects of botnets.

So the answer is yes, since it might not be 'occasional'.

d/

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Jul 2014 10:46:53 -0400

> Well, OK.  What would be the proper MX for mail sent to [email-masked] ?

divertimento% dig mx ietf.org

; <<>> DiG 9.8.3-P1 <<>> mx ietf.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44344
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ietf.org.                      IN      MX

;; ANSWER SECTION:
ietf.org.               494     IN      MX      0 mail.ietf.org.

;; Query time: 100 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Fri Jul 18 10:46:25 2014
;; MSG SIZE  rcvd: 47

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Jul 2014 10:48:27 -0400

> Ahhh.  You haven't heard of the scaling effects of botnets.

OK, so the NULL MX record is actually intended to make botnets send fewer TCP SYNs to non-mail-supporting hosts.   Got it.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Jul 2014 10:50:15 -0400

> the effort needed is tiny and one-time.

Understood, but it's not clear to me that "some operators" is a big enough target audience to see any appreciable win from this technique.

---

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

On Thu, Jul 03, 2014 at 12:03:47PM -0700, The IESG wrote:
> The IESG has received a request from the Applications Area Working Group
> WG (appsawg) to consider the following document:
> 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. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
>    Internet mail determines the address of a receiving server through
>    the DNS, first by looking for an MX record and then by looking for an
>    A/AAAA record as a fallback.  Unfortunately this means that the A/
>    AAAA record is taken to be mail server address even when that address
>    does not accept mail.  The NULL MX RR formalizes the existing
>    mechanism by which a domain announces that it accepts no mail, which
>    permits significant operational efficiencies.

So far so good, but the abstract does not mention that the I-D conflates
"does not accept e-mail" assertions with "does not send e-mail".  That
is a big deal, and it must at the very least be mentioned in the
abstract.

"Does not accept e-mail" assertions are a highly desirable optimization
for the delivery of non-derlivery notifications.  I see absolutely no
reason to conflate "does not accept" with "does not send", either in
mechanism or RFC.

Indeed, as the I-D mentions, the SPF already provides a method for
asserting "does not send e-mail".  By encouraging the inference "does
not accept implies does not send" this I-D leaves us with no mechanism
by which to indicate "does not accept but does send".

Consider automated job ("cron") e-mail.  There may be no return path.
But the received headers allow the recipient to find the source of the
e-mail and fix whatever problem might need fixing.  Causing such e-mail
to not be delivered would be a serious problem.

Please do not publish this I-D as-is.  Please remove the "does not
accept" -> "does not send" inference and mechanism from the text.
Otherwise this I-D will likely cause harm.

Nico
--

---

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: Dave Crocker <[email-masked]>
Date: Fri, 18 Jul 2014 08:03:41 -0700

> Understood, but it's not clear to me that "some operators" is a big enough target audience to see any appreciable win from this technique.

Ted, I can't tell what sort of actions you are pressing to have taken.

The document formalizes existing practice.  Sometimes the IETF does that.

d/

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Jul 2014 11:06:20 -0400

> Ted, I can't tell what sort of actions you are pressing to have taken.

I'm not asking for action to be taken.   I'm making an observation, and waiting for you to either ignore it, contradict it, or agree with it.

---

From: [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: Hector Santos <[email-masked]>
Date: Fri, 18 Jul 2014 11:16:00 -0400

Null mx would be a plug and play logical signal, condition to stop, preempt, do not queue, skip the outbound "send mail" process for the email domain because this proposal says its an indicator there would be no listening server ip available.  In other words, it's an optimizer.  It would be networking waste to do make the call. The issue I have are false positives.  Do we know for a fact, there are no legitimate mx records with explicit preference zero settings with legitimate ip receivers?  Should we believe them?

I might suggest a better algorithm where a first time attempt is made to double check if there is no legitimate ip or server to connect to. A implicit mx attempt is already done to block the domain by our software and tony also mentioned the same in Exim.  I assume it is a long time common thing.   I think I can say for a support fact that there are false positives, but maybe not significant to not kill the idea of a single shot attempt.  I think the "dynamic DNS domain" services are some of the main reasons for intermittent errors.  The few times over the years were handled manually when reported.   The pref equal zero offers a new rule to avoid the single shot attempt. But I am not sure if it's worth the coding change the avoid the outbound mail attempt.   Note, I know in our software we reduced the TCP/IP timeout from a default if about 30 secs to 10 secs depending on the socket stack so it's less of a loading/performance concerns.

--
Hector Santos
http://www.santronics.com

> On Jul 17, 2014, at 9:06 PM, Dave Crocker <[email-masked]> wrote:
>

---

From: Hector Santos <[email-masked]>
Date: Fri, 18 Jul 2014 11:58:43 -0400

> On Jul 18, 2014, at 7:50 AM, Ted Lemon <[email-masked]> wrote:
> 

It could be useful as an optimizer to avoid the implicit mx step.  It can also help with any CBV "call back verifiers" support to immediately skip checking the return path dynamically at the SMTP level.  This would provide your receiver with a "55z 5.5.z invalid return path" dynamic rejection at the 5321 mail from or rcpt to state point.

So in this regard, on the receiver side, it is definitely become a valid SMTP compliance check with an enforceable reason to reject regardless of the mail legitimacy. On the sender side, it's an optimizer to avoid the implicit mx attempt.

---

From: "John Levine" <[email-masked]>
Date: 18 Jul 2014 17:50:29 -0000

Perhaps this will alleviate some confusion.

* All this draft does is define an MX that says "you can't send mail
  here."  It's intended for domains that handle no mail at all, but get
  mail anyway due to typos or brain-os.  There's no hidden agenda.
  Really.

* It has been widely implemented in Exim, Postfix and other MTAs for
  nearly a decade.  If there were severe damage, we'd probably have
  noticed by now.  The fact that it's widely implemented suggests that
  people find it useful.

* The part in the draft about sending and receiving was confusing
  and unhelpful, so I rewrote it.  Now it says you SHOULD NOT send mail
  from a domain that publishes null MX.  This is both on principle,
  don't send mail if you don't want an answer, and practice, since many,
  many MTAs reject mail from domains without a resolvable mail server.
  (Remember, SHOULD NOT means don't do this if you want to interoperate.)

R's,
John

---

From: [email-masked]
Date: Fri, 18 Jul 2014 10:58:51 -0700 (PDT)

>   (Remember, SHOULD NOT means don't do this if you want to interoperate.)

The closest existing code is 5.4.4 Unable to route:

         The mail system was unable to determine the next hop for the
         message because the necessary routing information was
         unavailable from the directory server.  This is useful for both
         permanent and persistent transient errors.

         A DNS lookup returning only an SOA (Start of Administration)
         record for a domain name is one example of the unable to route
         error.

But this isn't quite right, because this is for when there's no relevant DNS
information at all. And for diagnostic purposes it makes sense to be able to
distinguish "no entry in DNS" from "DNS says host doesn't accept mail"

Which is what I was trying to say; this really deserves a new 5.4.x code.
As for text, how about:

X.4.8 Destination does not accept mail

         The directory server has returned an indication that the
         next hop is incapable of accepting mail.

         In the case of a DNS lookup, this can be indicated through the
         use of a null MX entry [this rfc].

Or something along those lines. (8 may not be the right code, but it what
the IANA registry says is correct.)

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2014 15:02:58 -0400

>         use of a null MX entry [this rfc].

OK with me if it's OK with everyone else.

Meta-question: this code would presumably also apply for domains that 
don't exist or have no records (NXDOMAIN or NOERROR with no answers.)  I 
am not eager to do yet another draft, but it's more generally applicable 
than for null MX.

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 18 Jul 2014 20:39:49 +0100

On 18 July 2014 20:02, John R Levine <[email-masked]> wrote:
> don't exist or have no records (NXDOMAIN or NOERROR with no answers.)  I am
> not eager to do yet another draft, but it's more generally applicable than
> for null MX.
>

Wouldn't that be the 5.4.4 that Ned mentioned? It seemed to mean "No idea
how to route there".

Whereas 5.4.8 is "explicitly does not handle mail".

Dave.

---

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

> The closest existing code is 5.4.4 Unable to route:

What's wrong with 5.1.2 and 5.1.8 ?

      X.1.2   Bad destination system address

         The destination system specified in the address does not exist
         or is incapable of accepting mail.  For Internet mail names,
         this means the address portion to the right of the "@" is
         invalid for mail.  This code is only useful for permanent
         failures.

      X.1.8   Bad sender's system address

         The sender's system specified in the address does not exist or
         is incapable of accepting return mail.  For domain names, this
         means the address portion to the right of the "@" is invalid
         for mail.

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: "John R Levine" <[email-masked]>
Date: 18 Jul 2014 15:52:24 -0400

>         means the address portion to the right of the "@" is invalid

Those look right to me.  Will adjust accordingly.

Regards,

---

From: [email-masked]
Date: Fri, 18 Jul 2014 13:14:04 -0700 (PDT)

>          means the address portion to the right of the "@" is invalid

Wrong group of codes. Those are status for mail systems to return, not
the routing layer.

				Ned

---

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

> Wrong group of codes. Those are status for mail systems to return, not

The point of null MX records it to explicitly say the address is invalid,
so an address status would seem to make sense.

      X.1.XXX Addressing Status

         The address status reports on the originator or destination
         address.  It may include address syntax or validity.  These
         errors can generally be corrected by the sender and retried.

An invalid address isn't a problem with the DNS itself.

      X.4.XXX Network and Routing Status

         The networking or routing codes report status about the
         delivery system itself.  These system components include any
         necessary infrastructure such as directory and routing
         services.  Network issues are assumed to be under the control
         of the destination or intermediate system administrator.

Looking through the X.4.X codes, I can't tell whet is the distinction
between 5.1.2 and 5.4.4. The text for X.4.4 has a weird description of a
nodata / nxdomain response, which is exactly the same as "does not exist"
under X.1.2.

There's evidently a lot of overlap and lack of precision in how these
codes are defined and used so I don't think it matters in practice what
this draft picks.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire: Variable, mainly northerly or
northeasterly 3 or 4, veering easterly 4 or 5 later. Slight. Fog patches
developing. Good, occasionally very poor.

---

From: [email-masked]
Date: Fri, 18 Jul 2014 14:18:58 -0700 (PDT)

> so an address status would seem to make sense.

No, the point is to say that a host is invalid.

> An invalid address isn't a problem with the DNS itself.

Neither is a NXDOMAIN error, and that's in the 4.z group.

> nodata / nxdomain response, which is exactly the same as "does not exist"

Again, it's a question of what component is involved. 4.x codes are
for directory services external to the mail system, 1.x is for the mail
system itself.

Which admittedly leaves LDAP in a bit of an odd position. Oh well.

> codes are defined and used so I don't think it matters in practice what

On the contrary, it matters because the DNS changes constantly, and
the code may be all you have telling you what the condition was that
caused the bounce.

				Ned

---

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

> No, the point is to say that a host is invalid.

If you can't use them when the DNS says a mail domain is invalid then I
don't understand if it ever makes sense to use 5.1.2 or 5.1.8.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South-east Iceland: Southeasterly 4 or 5. Moderate. Occasional rain. Good,
occasionally poor.

---

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

In message <[email-masked]>, Ted Lemon writes

> server, is actually served better by setting up a proper MX that directs
> the mail to the right server.   Does an HTTP server really care about the
> occasional SYN to port 25?

Is it?  You are forcing me to configure a MTA to accept mail for
"www.example.com", even if I don't want to, because otherwise I
have to trust a hosting service to not run a smtp service on the
http server.  I'm giving the hosting service stuff I want to be
made public.  I want to prevent stuff, that should remain private,
from being sent to their machine by mistake.

---

From: [email-masked]
Date: Fri, 18 Jul 2014 17:08:23 -0700 (PDT)

> don't understand if it ever makes sense to use 5.1.2 or 5.1.8.

You don't have a way of declaring a domain as invalid at the MTA level? The
Oracle MTA has at least five different ways that can be configured without any
recourse to a directory server. And we absolutely do return 5.2.1 in such
cases.

And ask yourself this: Given that the null MX mechanism wasn't part of the
picture when these codes were developed, and given null MX is the only (AFAIK)
DNS-based mechanism with these semantics, why was the code even defined? Also
remember that the attitude in those days (wrongly, IMO) to be parsimonous
with code allocation.

Absent a DNS-based mechanism, the best that could be done to address this
problem was either to MX such hosts to an MTA which was configured to reject
them, or run a stub SMTP server on the host itself that returns a 521 error as
the banner a la RFC 1846. In either of those cases a 5.1.2 code would be
appropriate.

				Ned

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 19 Jul 2014 00:47:27 +0000

On Fri, Jul 18, 2014 at 07:50:28AM -0400, Ted Lemon wrote:

> I must be missing something here.   You're saying you want me to set up
> a null MX for all my hosts to prevent someone else's MTA having

This is very use to prevent misuse of parked domains.  These
sometimes become live, or in any case misuse of these by spammers
can negatively impact one's brand reputation.  If one has a domain
that is never used to send mail, a nullmx is a sensible thing to
publish.  One is of course free to not publish nullmx RRs, or not
even consider the question.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 19 Jul 2014 01:53:13 +0000

> No, the point is to say that a host is invalid.

A recipient domain is (often) not a host.  The lookup key for a
nullmx RR is a domain.  Since no MX hosts are returned, what is
invalid is the recipient domain, which is part of the recipient
address.  I generally also have mappings in the Postfix transport
table of the form:

	.invalid	error:5.1.2 invalid destination domain

and rewrite unqualified mailboxes in headers from remote clients
by appending "@domain.invalid".

    http://www.postfix.org/postconf.5.html#remote_header_rewrite_domain

The text in 3463 is quite broad:

It applies equally well to nullmx and the "invalid" TLD.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 19 Jul 2014 05:59:23 +0000

On Fri, Jul 18, 2014 at 10:46:53AM -0400, Ted Lemon wrote:

> > Well, OK.  What would be the proper MX for mail sent to [email-masked]?
> 

Sorry, no, that would be "dig mx www.ietf.org":

    $ dig +noall +ans -t mx www.ietf.org
    www.ietf.org.  IN  CNAME  www.ietf.org.cdn.cloudflare.net.

so no MX records there...

-- 
	Viktor.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 19 Jul 2014 01:14:34 -0700

Hi John,
>Well, OK.  What would be the proper MX for mail sent to [email-masked] ?

That's a good question.  I'll explain the problem as follows:

   (a) The user uses an incorrect email address for the recipient.

   (b) The mail service does not provide timely feedback about not
       being able to deliver the message (see (a)).

The fix proposed is to signal that the mail target does not support a 
mail service.  It's not a bad idea.  Now, how do you (used in a 
general sense) do that?  Currently, there isn't any way to do that 
because of the implicit MX.  There was a fix proposed over nine years 
ago.  It was to use a dot as the mail target.  From an application 
point of view, what the dot means is a DNS problem. :-)  From a SMTP 
point of view, the target host is not valid; the user will be sent a 
message in about four hours with information about the delivery status.

The MX RDATA format, defined in an Internet Standard, is as follows:

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

There is a problem.  The IETF can:

    (a) Solve it.

    (b) Pretend that it does not exist.

    (c) Wait.

I do not have a strong opinion about all.

Regards,
S. Moonesamy

---

From: Tony Finch <[email-masked]>
Date: Sat, 19 Jul 2014 14:09:24 +0100

Ned Freed <[email-masked]> wrote:
> You don't have a way of declaring a domain as invalid at the MTA level?

Yes, but it doesn't make much sense to me to draw an arbitrary line
somewhere on the spectrum between a configuration file, a configuration
table, a configuration database, or getting configuration from LDAP or
DNS, and say that one one side of the line it is an address-related
failure and on the other it is a routing or directory related failure.
In some MTAs, you find out whether an address is valid by trying to route
it.

> DNS-based mechanism with these semantics, why was the code even defined?

At least some MTAs in the mid 1990s would treat a mail domain as invalid
if its DNS was set up incorrectly, e.g. MX points to this machine but this
machine isn't configured to handle the domain, or MX does not exist in a
part of the DNS where the postmaster has forbidden fallback-to-A.

> the banner a la RFC 1846. In either of those cases a 5.1.2 code would be

Why not a 5.3.X (mail system status) code?

The problem here is that someone writing a specification for a status code
can't choose which sub-code to use based on just RFC 3463 since the
categories overlap and their descriptions are too abstract to make it
clear how to resolve the overlaps. (Another example: why are message size
limits a "mail system status" not a "message content status"? You have to
read between the lines to conclude that X.6.X is exclusively for MIME.)
And you can't use your practical experience of MTA architecture since
implementations differ a lot and the codes are evidently not based on a
sufficiently universal model.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southwest Forties, Cromarty, Forth: Easterly 4 or 5, increasing 6 or 7 for a
time, veering southerly or southwesterly later. Slight or moderate,
occasionally rough later in Cromarty. Thundery showers, fog patches later.
Moderate or poor, occasionally very poor later.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 19 Jul 2014 14:25:29 +0000

On Thu, Jul 17, 2014 at 06:06:42PM -0700, Dave Crocker wrote:

> > It just designates non-sending domains,
> 

That's a bit of an under-statement, because, for example,
with the widely practived:

    reject_unknown_sender_domain

restriction in Postfix, mail from nullmx domains *is* rejected,
so any that declare-themselves non-receiving become non-sending
in practice.  If the draft suggests that nullmx domains might
expect to send mail will impunity, that would be misleading.

In practical terms, if you don't receive, you can't send (that is
you can't use the domain in the SMTP return path).

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Jul 2014 10:38:14 -0400

> you can't use the domain in the SMTP return path).

Sorry, no.

   1. The return-path is not required to have any relationship to any
another email field.

   2. The semantics of nullmx make an assertion only about receiving.

In fact, there are legitimate scenarios that include use of domains used
for sending but not receiving, as the draft cites.

The fact that some operational choices might not allow this scenario is
a separate matter, outside of IETF specifications.

d/

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2014 10:50:26 -0400

>   (b) Pretend that it does not exist.

   (d) Document the exisiting practice that people have been using since 2006.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 19 Jul 2014 11:01:46 -0400

>    (d) Document the exisiting practice that people have been using since

   (e) Document the existing practice that people have been using since 2006, 
but give it a new name so that those people have no idea you've done it 
because a semantically correct name is better than one that people know.

Scott K

---

From: [email-masked]
Date: Sat, 19 Jul 2014 07:49:03 -0700 (PDT)

> In some MTAs, you find out whether an address is valid by trying to route

I quite simply disagree. To me it makes a hell of a lot of sense to draw a line
between errors caused by stuff under the control of my administrative domain
and stuff that isn't.

This is especially true of the DNS, where an error right now may not occur
later, and there's nothing logged locally to indicate the change.

I don't even want to think about how many hours I've spent personally trying to
sort out some obscure problem that was made obscure by it not being clear that
the error condition originated from the DNS.

> part of the DNS where the postmaster has forbidden fallback-to-A.

Unless there's some indication that the existence of that practice was a factor
in the design - and I'm pretty sure it wasn't - I fail to see the point.

> Why not a 5.3.X (mail system status) code?

Perhaps because none of those codes are appropriate?

> sufficiently universal model.

I agree that the categories in general overlap and that some of the
descriptions are unclear.

But that doesn't mean they are unclear in this case, or that we should
just throw up our hands and use whatever code we happen to feel like
using.

The real question is whether or not it makes sense to define a new code to
identify this class of error. I think it makes all sorts of sense to do so, and
I think that code belongs in the 4.x space.

				Ned

---

From: Nico Williams <[email-masked]>
Date: Fri, 18 Jul 2014 11:16:32 -0500

It's been pointed out that senders must be willing to receive bounces.
I withdraw my objection.

Nico
--

---

From: Ted Lemon <[email-masked]>
Date: Sat, 19 Jul 2014 17:33:00 -0400

> Sorry, no, that would be "dig mx www.ietf.org":

You misunderstand.   I was suggesting that the MX record for ietf.org be used as a template for other non-mail-receiving subdomains of ietf.org.

(To avoid further controversy, though, the responses I've gotten on this topic have been generally helpful, and I am not asserting that this should be done instead of what has been proposed.   I was merely floating it to see what the objection would be, and the response was informative.)

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Jul 2014 09:24:37 -0400

> so no MX records there...

But there are address records.

www.ietf.org.cdn.cloudflare.net. 87 IN	A	104.20.1.85
www.ietf.org.cdn.cloudflare.net. 87 IN	A	104.20.0.85
www.ietf.org.cdn.cloudflare.net. 116 IN	AAAA	2400:cb00:2048:1::6814:55
www.ietf.org.cdn.cloudflare.net. 116 IN	AAAA	2400:cb00:2048:1::6814:155

http://tools.ietf.org/html/rfc5321#section-5
,--
If an empty list of MXs is returned,
the address is treated as if it was associated with an implicit MX
RR, with a preference of 0, pointing to that host. 
'--

Which means there are 4 implied MX records causing likely 4 timeouts depending on how port 25 is handled.
Since there is no support to require use of MX records, the remaining solution (although not as clean) is to create negated MX record.

Regards,
Douglas Otis

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 21 Jul 2014 15:14:52 +0000

> a separate matter, outside of IETF specifications.

One can bury one's head in the sand if one likes, but non-receiving
domains that turn on nullmx (or whatever it ends up being called)
need to be aware that in practice they will find their mail rejected
by many receiving systems if they attempt to use such a domain in
the "MAIL FROM:<return-path>".

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2014 17:08:16 -0000

>the "MAIL FROM:<return-path>".

As I think I said in the summary note a few days ago, my updated copy
of the draft now says pretty much that.

R's,
John

---

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