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

From: The IESG <[email-masked]>
Date: Thu, 03 Jul 2014 12:03:47 -0700

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

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 16 Jul 2014 02:46:08 -0700

Hello,
>[email-masked] mailing lists by 2014-07-17. Exceptionally, comments may be

This intended Proposed Standard is a change to Section 5 of RFC 
5321.  The draft mentions that indirectly in the Introduction section.

 From Section 4:

   "The NULL MX record has a variety of efficiency and usability
    benefits."

One interpretation of the word "usability" is the "effectiveness, 
efficiency and satisfaction with which specified users achieve 
specified goals in particular environments".  I don't think that it 
applies here.

The heading of Section 4 is "Effects of NULL MX".  The sentence in 
that section is a little like marketing prose.

 From Section 4.2:

   "Mail often has an incorrect address due to user error, where the
    address was mistranscribed or misunderstood, for example, to
    [email-masked] or [email-masked] or [email-masked]
    rather than [email-masked].  NULL MX allows a mail system to
    report the delivery failure when the user sends the message, rather
    than hours or days later."

The problem mentioned above looks similar to the problem that RFC 
7208 attempts to solve.  In simplistic terms, the IETF would be 
standardizing another mechanisms to do the same thing.

I took a quick look to verify the reply code and enhanced status code 
(see Section 4.3) and I did not spot any problem.

 From Section 5:

   "SMTP mail is inherently insecure since it does not validate any of
    the e-mail addresses in the message or envelope."

I gather that the security issue is about the authentication issues 
associated with SMTP.

I did a test to see what my MTA does when the recipient's domain has 
a NULL MX record.  A DSN was generated because of "Name server: .: no 
data known".

 From a DNS perspective this proposal is not aligned with what is 
specified in RFC 1035.  Shouldn't this proposal update RFC 1035?

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jul 2014 19:21:09 -0700

On 7/16/2014 2:46 AM, S Moonesamy wrote:
> efficiency and satisfaction with which specified users achieve specified
> goals in particular environments".  I don't think that it applies here.

Whereas I think it applies reasonably well, and the Wikipedia opening
sentencefor the term:

     "ease of use and learnability of a human-made object."

works nicely to0.  The point behind the use of that word in this text is
that it is simple for operators to set up and for queriers to query and
for everyone to understand.

In any event, what do you think is problematic with the use of the word
here and what other wording would you suggest and why?

> The heading of Section 4 is "Effects of NULL MX".  The sentence in that
> section is a little like marketing prose.

Which text, in particular, and what alternate phrasing would you suggest?

> The problem mentioned above looks similar to the problem that RFC 7208
> attempts to solve.  In simplistic terms, the IETF would be standardizing
> another mechanisms to do the same thing.

SPF pertains to sources.  Nullmx pertains to destinations.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 16 Jul 2014 22:33:34 -0400

> SPF pertains to sources.  Nullmx pertains to destinations.

Section 4.3 covers that.  If it's not clear enough, people can feel free 
to send text.

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

---

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:
> Hi.  For a number of reasons, many of which have been identified
> by others, I find this draft and the actions it recommends
> distasteful. 

Since I'm the doc shepherd:

     I have not seen statements by others indicating that the
specification is 'distasteful', although there have been some that
seemed to confuse its functionality with that of SPF.

     Feel free to cite the specific comments by others that classed this
as distasteful or the equivalent.

> I see it as another step, albeit a small one, in
> the direction of prioritizing the prevention of unwanted
> messages or connections over successful delivery of legitimate
> messages. 

A statement of "I don't do X" does not 'prioritize' anything.

The use of information that says "target address Y will not work because
there is not receiver at Y's domain" does not 'prioritize' anything.

The specification is nothing more than a vastly more efficient form of
getting an SMTP 550 Requested action not taken: mailbox unavailable,
except that it is even better than that, because it also precludes
waiting days to discover that there's no service to supply even that
error message.

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

You do not clearly indicate any historical inaccuracy at issue.

> The last sentence of the second paragraph of Section 5
> ("Security Considerations") of the spec says:
> 
> 	"The normal way to send mail for which a sender wants no
> 	responses remains unchanged, by using an empty
> 	RFC5321.MailFrom address."
> 
> First, two issues of terminology:
> 
> (1)  RFC 5321 does not contain or specify notations like
> "RFC5321.MailFrom".  That notation was introduced in RFC 5598, a
> document that was approved as Informational with a consensus
> that, IIR, included some significant desire that it not be
> normative or casually treated as normative.  If this

First, so what?

Second, a review of the IETF mailing list archive about the document's
Last Call, in May of 2009, shows a nicely solid pattern of support for
the document's publication.  Strange that you would call it into
question at this point.

> specification wants to use that notation, that is fine.  But it
> should include an explicit note to that effect in its
> introduction or a Terminology section, not bury a "(see
> [RFC5598] for the definitions of these terms)" reference in a
> parenthetical note in Section 4.1 and then expect readers who
> are looking specifically at other sections to pick up on it.

If you want specific text changes, please suggest specific text changes.

Please do not formulate a requirement for change in a fashion that
leaves the authors having to guess whether it will satisfy you.

> I believe that the RFC Editor's principle is that, if particular
> terminology is needed to correctly understand a specification,
> then the reference to the document that defines that terminology
> is normative.  In this particular case, it seems inconsistent to
> consider 2119 normative and 5598 informative since both are used
> to define terminology without which the document cannot be
> correctly understood.

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

> (2) Second, RFC 5321 does not contain a concept that it calls an
> "empty address".  The terminology it does use is "null
> reverse-path" (See RFC 5321, Section 3.7).  Subject to the
> above, if the authors want to say "null address in
> RFC5321.MailFrom", I don't think that is sufficiently confusing
> to be a problem.  But "empty address" could be construed as 
>    MAIL FROM: 
> in the envelope with nothing following it, and that would be bad
> news.

So you are suggesting:

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

> More important, however, RFC 5321 specifies the use of a null
> reverse path only for delivery failure and status notifications
> and message disposition notifications (see Section 4.5.5 of RFC
> 5321) and constrains the recipient address to be used.     That
> section also says 
> 
> 	"All other types of messages (i.e., any message which is
> 	not required by a Standards-Track RFC to have a null
> 	reverse-path) SHOULD be sent with a valid, non-null
> 	reverse-path."

And here I was, thinking that "SHOULD" means it is ok /not/ to do what
is being directed, if you have a good reason.  Oh, wait...

> Specifically referring to Section 3 of
> draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL
> MX Resource Record".  There is only an MX Resource Record that
> this specification proposes to use with a convention involving
> specific content in the DATA.  One could call that many things,
> but "NULL MX Resource Record" isn't one of them.  

By my reading of that section, it is defining the term, if only by
virtue of the way it is used in the name of that section.

Perhaps your confusion would be resolved if the term had a comma in it,
so:  NULL, MX Record?

In other words, NULL is an adjective within the term.

If you would prefer a different term, please suggest one.

> (b) I think I know what the second paragraph of 4.1 in intended
> to convey but I have now read it several times and can't be sure
> that it what is says.  The parenthetical terminology note
> doesn't help with readability but the problem exists even
> without it.

Take a look at the sub-section's title.  Note that the first paragraph
reviews benefits for an SMTP client and then note that the second
paragraph extends into talking about a particular benefit for a
receiving SMTP server, per the section's title.

NullMX allows a receiving SMTP server to detect when a return-path
address uses a domain name that does not receive mail.  Hence, at
submission time, the receiving server can reject such messages.

> (e) The issues identified above aside, the explanation in the
> second paragraph of Security COnsiderations (Section 5) is
> unsatisfying.  If a domain is configured so that some sending
> hosts don't receive and some receiving hosts don't send, the
> model specified in this document may simply be inappropriate and
> shouldn't be used lest it cause lost messages.  Why can't that
> simply be said, and said clearly (probably in another section
> referenced from this one.

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

d/

---

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

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.

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

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

regards,
   john

---

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: Nico Williams <[email-masked]>
Date: Thu, 17 Jul 2014 17:38:51 -0500

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

>two assertions should be separate both, in terms of mechanism and

I must be unusually stupid today, because when I read section 4.3, it
says to me that null MX means "I don't receive mail" and SPF -all
means "I don't send mail".

It also notes the reality that a lot of mail server operators don't
want mail from places that don't accept replies.  Can you blame them?

If this isn't clear, send text.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 17 Jul 2014 23:32:44 -0000

>by which to indicate "does not accept but does send".

PS: The term of art for such domains is "spammers".  Mail operators I
know go to considerable lengths to avoid such mail.  We're the IETF,
we can only tell people how to interoperate.  We can't tell them to do
anything they aren't already inclined to do.

>Consider automated job ("cron") e-mail.  There may be no return path.

Then there is no domain, and no null MX.  I really have no idea what
point you're trying to make here.

R's,
John

---

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: Steve Atkins <[email-masked]>
Date: Thu, 17 Jul 2014 17:04:55 -0700

> point you're trying to make here.

The draft does mention RFC5322.From in sections 4.1 & 4.3, which seems
marginally controversial and not essential.

Cheers,
  Steve

---

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

Upon further consideration of John Klensin's note, I have considerable
sympathy for much of what he says.  This is an ordinary MX, one that
used to have ambiguous meaning, and this removes the ambiguity, so I
made "null" lower case and made a few other changes to clarify that
it's an ordinary MX record.  The point about RFC 5598 is reasonable,
so I moved the reference to it up to the Conventions section.

The intended use of null MX is for domains that don't intend to do
mail at all but get mail anyway due to mistakes.

So I'm thinking of replacing 4.3 with this:

4.3. Sending Mail from Domains that Publish Null MX

  Null MX is primarily intended for domains that do not send or
  receive any mail, but get mail anyway due to typing errors and other
  mistakes.  Many mail systems do not welcome mail with return addresses
  that will not accept replies, both because it defeats the
  interactive nature of e-mail, and because such mail has a high chance
  of being spam.  Hence mail systems SHOULD NOT send mail with
  RFC5321.MailFrom or RFC5322.From addresses in domains that publish a
  null MX record.

  Operators of domains that do not send mail can publish SPF -all
  [RFC 7208] policies to make an explicit declaration that the
  domains send no mail.  Null MX is not intended to be a replacement
  for the null reverse path described in RFC 5321 section 4.5.5 and does
  not change the meaning or use of a null reverse path.

This is a 2119 SHOULD NOT, as in don't do that if you want to interoperate.

R's,
John

---

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:
> 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: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 18 Jul 2014 12:58:57 +0200

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

I don't recall reading this in the document. It's a good point. IM personal 
O it's more important than either 4.1, 4.2 and 4.3. Add it, please.

Arnt

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Jul 2014 04:02:40 -0700

On 7/18/2014 3:58 AM, Arnt Gulbrandsen wrote:
> I don't recall reading this in the document. It's a good point. IM
> personal O it's more important than either 4.1, 4.2 and 4.3. Add it,
> please.

   4.1.  SMTP Server Benefits
   ...
   A receiving SMTP server that chooses to reject email during the SMTP
   conversation that presents an undeliverable RFC5321.MailFrom or
   RFC5322.From domain (see [RFC5598] for the definitions of these
   terms) can be more confident that an attempt to send a Delivery
   Status Notification or other response will reach a recipient SMTP
   server.

How is it that this existing text does not suffice for that purpose?

Or is it merely that you'd be happier with different wording?  If so,
please do please offer some.

d/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 18 Jul 2014 13:40:36 +0200

> please do please offer some.

Different emphasis.

The point is that the message should not cross a point if a DSN would not 
be able to cross the same point on the way back, because that loses 
information for the sender. And 4.1 does say that if you read it closely 
enough, it just doesn't point out that this information loss might matter 
to the message's sender.

I tried rewriting, but my wording wasn't happy under the headline "SMTP 
Server Benefits". I like it better under 4.3: "If a sender erroneously 
tries to send a message from a domain with a null MX, then rejecting the 
message during the SMTP conversation ensures that the sender receives an 
appropriate Delivery Status Notification or other error report."

Arnt

---

From: Ned Freed <[email-masked]>
Date: Fri, 18 Jul 2014 07:42:41 -0700 (PDT)

> O it's more important than either 4.1, 4.2 and 4.3. Add it, please.

I agree with Arnt here. Not having a code for this is an obvious omission,
and this is chance to address it.

				Ned

---

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: S Moonesamy <[email-masked]>
Date: Fri, 18 Jul 2014 08:11:05 -0700

Hi Dave,
>here and what other wording would you suggest and why?

The term "usability" usually occurs in discussions about User 
Experience.  I don't think that the term applies here (personal opinion).

>Which text, in particular, and what alternate phrasing would you suggest?

The sentence (re. has a variety of ...) can be interpreted as a 
marketing as it claims benefits without providing an information 
about those benefits.  I am not suggesting adding more text in the 
draft as it would only make the draft longer.  I am okay at leaving 
the sentence (Section 4) if that's the consensus.

>SPF pertains to sources.  Nullmx pertains to destinations.

Yes.

John commented about that (re. Section 4.3).  I understood the 
meaning of the text in Section 4.3; I am not a good data point in 
this case as I usually review SMTP stuff.

I have been running an autoresponder for a while.  In my opinion most 
people who send a message to it expect a reply.  One problem I 
noticed is that some messages have an incorrect return-path.  My 
guess is that it is probably due to misconfiguration at the sender's 
end.  At my end the return-path is considered as correct as there is 
the implicit MX for the domain on the right-hand side of the @.

 From an architectural point of view I would describe the problem as 
a disconnect between the sender and the receiver (words used 
loosely).  Without spending more than a few seconds to think about 
this I would say that the return-path provides a feedback loop (re. 
DSNs).  SPF provides a mechanism for validation of the source.  The 
receiver does not have to generate a DSN when that validation is done 
during the SMTP session.  In other words, there is already a solution 
for the destination problem.  The outstanding issue would be the DNS 
specifications; my light suggestion would be to cross-check that.

Regards,
S. Moonesamy

---

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

> On Jul 17, 2014, at 8:44 PM, "John Levine" <[email-masked]> wrote:
> 

I don't think null, in any letter case, is right. Only geeks know what this means.  It is a mx record with a preference of zero. This proposal is setting a specific and special definition, a rule, for a specific value.  In fact, it  goes from one extreme meaning of top level first preference call sorted ordered value to the other extreme of "do to bother to send" semantics.

> mail at all but get mail anyway due to mistakes.

I don't quite follow. Sound like there could be false positives. What mistakes?  It thought it is for the outbound sender to avoid an queuing of outgoing mail attempt to domains?

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

---

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

>and this is chance to address it.

Please send text, or at least a three part number.

R's,
John

---

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: Dave Crocker <[email-masked]>
Date: Fri, 18 Jul 2014 09:44:25 -0700

> Experience.  I don't think that the term applies here (personal opinion).

SM,

The humans who runs these systems qualify as users, albeit of the
administrative side of things.  They, too, qualify for consideration of
usability factors.  OA&M designs that are difficult for the human
administrators have poor usability.

The point behind saying that nullmx has good usability is to claim that
the ops folks can easily understand it and easily use it -- where 'use'
on the name ownership side means configuring the DNS record and on the
email-sending side means writing code that looks for nullmx and properly
processes the message when a nullmx is found.  (So as controversial as
it might seem, yes, I'm classifying programmers as users too.)

> marketing as it claims benefits without providing an information about
> those benefits.  I am not suggesting adding more text in the draft as it
> would only make the draft longer.  I am okay at leaving the sentence
> (Section 4) if that's the consensus.

Would one or two sentences that try to summarize the nature of those
benefits -- perhaps along the lines of what I wrote above, suffice?  If
not, then what?

...
> From an architectural point of view I would describe the problem as a
> disconnect between the sender and the receiver (words used loosely). 
> Without spending more than a few seconds to think about this I would say
> that the return-path provides a feedback loop (re. DSNs).  SPF provides
> a mechanism for validation of the source. 

Specifically its semantics means "the host with this IP Address" is
authorized to /transmit/ mail that has this domain name in the
return-path address.

The semantics of SPF do not say anything about whether that host is able
or authorized to /receive/ mail for that domain.

> The receiver does not have to
> generate a DSN when that validation is done during the SMTP session. 

Broadly, a DSN would be expected whenever the handling host discovered a
termination error.  (That's separate from the strategic decision not to
issue a DSN as part of an anti-abuse policy.)

> In
> other words, there is already a solution for the destination problem. 

That sentence lost me.  I don't see how it follows from the preceding
sentence and I don't know what it means.

> The outstanding issue would be the DNS specifications; my light
> suggestion would be to cross-check that.

And I don't understand this one.

d/

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2014 20:03:31 -0400

>> Experience.  I don't think that the term applies here (personal opinion).

The specific user experience we had in mind is that misaddressed mail 
comes back to the user immediately rather than a week later.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Fri, 18 Jul 2014 17:49:51 -0700 (PDT)

> comes back to the user immediately rather than a week later.

And this can be achieved with a simple bit of DNS configuration rather than
other more complicated techniques that busy sysadmins don't have the time
to set up and maintain. (And in practice they don't set up and maintain.)

This is the real win as fas as I'm concerned. There are other ways to do this,
but they all suck.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Sat, 19 Jul 2014 08:33:22 -0700

Hi Dave,
>benefits -- perhaps along the lines of what I wrote above, suffice?  If

I'll say that the issue has been addressed.  As a matter of 
preference I would not suggest having more text.

>sentence and I don't know what it means.

There was some discussion (I forgot on which thread) about the sender 
and receiver perspectives.  What I was trying to say is that the 
problem is what John explained on [email-masked] (the domain does not 
receive mail).

>And I don't understand this one.

Sorry, see the "MX RDATA format" comment at 
http://www.ietf.org/mail-archive/web/ietf/current/msg88674.html

Regards,
S. Moonesamy

---

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