A "Null MX" No Service Resource Record for Domains That Accept No Mail
RFC 7505

Note: This ballot was opened for revision 07 and is now closed.

(Richard Barnes) Yes

Comment (2014-08-06 for -07)
No email
send info
It seems like it would be worth documenting the fact that this is likely to result in increased bogus traffic to the DNS root.  Just because "." is technically not valid doesn't mean that some DNS libraries won't accept it.  For example, `dig . A` will happily send a query.  But the root is already used to dealing with noise, and in exchange for increasing that noise floor a little, we get to potentially reduce mail noise by a lot.  So the trade-off is worth making, but it would be nice to document it.

(Brian Haberman) Yes

Comment (2014-08-05 for -07)
No email
send info
Section 4.1 uses the acronym "DSN" without any expansion.  I assume this expands to Delivery Status Notification, which is used later in the section.

Barry Leiba Yes

Comment (2014-08-06 for -07)
No email
send info
Version -07 added the downref to RFC 1846.

1. We intend to move 1846 to Standards Track.  That should happen quickly, but...

2. ...just to cover bases here, I intend to do a second last call on this document solely to call out the downref.  That way, even if the 1846 update doesn't go quickly, we're covered.

(Pete Resnick) Yes

(Jari Arkko) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2014-08-05 for -07)
No email
send info
I have no objection to the publication of this document and you'll 
probably call me picky when I point to the last line in Section 3.

   A domain MUST NOT advertise multiple MX RRs including a null MX.

That says one of two things:
1. You must not advertise multiple MX RR if any one of them is a 
   null MX.
2. You must not advertise more than one null MX, but may advertise one
   null MX along with other MX RRs.

I think you mean the former in which case...

   A domain that advertises a null MX MUST NOT advertise any other 
   MX RR.

But, if you meant the latter that could also be clarified.

(Stephen Farrell) No Objection

Comment (2014-08-06 for -07)
No email
send info
Just curious - do we know or are we guessing that
this won't be an issue for DNSSEC (implementations)?
I've no info either way, so its purely curiosity,
really:-)

(Joel Jaeggli) No Objection

(Ted Lemon) No Objection

Comment (2014-08-07 for -07)
No email
send info
   Senders of abusive mail often use forged undeliverable return
   addresses.  Null MX allows DSNs and other attempted responses to such
   mail to be disposed of efficiently.

What's a DSN?   Please define in the terminology section, or add a reference saying that the reader should read (X), or just expand on first use: not all readers will have the SMTP RFCs memorized. :)

Also, it's not clear to me how this is a win unless the forged undeliverable return address has a null MX.   Is that the envisioned scenario?   If so, an additional sentence or two explaining why this is likely would help to justify the existence of this paragraph; otherwise I recommend just deleting it--it's not necessary, and on the face of it it seems implausible, but I'm not a spam expert, so maybe there's a reason of which I am not aware that the spammer would set this up, or use a fake domain for which a null MX exists.

(Kathleen Moriarty) No Objection

(Martin Stiemerling) No Objection