A "Null MX" No Service Resource Record for Domains That Accept No Mail
draft-ietf-appsawg-nullmx-10
Yes
(Pete Resnick)
No Objection
(Alissa Cooper)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Spencer Dawkins)
Note: This ballot was opened for revision 07 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(2014-08-06 for -07)
Unknown
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.
Brian Haberman Former IESG member
Yes
Yes
(2014-08-05 for -07)
Unknown
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.
Pete Resnick Former IESG member
Yes
Yes
(for -07)
Unknown
Richard Barnes Former IESG member
Yes
Yes
(2014-08-06 for -07)
Unknown
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.
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-08-05 for -07)
Unknown
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.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -07)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -07)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -07)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -07)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-08-06 for -07)
Unknown
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:-)
Ted Lemon Former IESG member
No Objection
No Objection
(2014-08-07 for -07)
Unknown
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.