Subject: [apps-discuss] draft-ietf-appsawg-nullmx-01

From: "John Levine" <[email-masked]>
Date: 21 May 2014 03:33:48 -0000

I finally updated the draft, based on the thorough Dave Crocker did
in February:

	http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/

As far as I know, nothing in the draft is contentious.  It still
refers to RFC 4408 rather than 7208 because for some reason 7208 isn't
in the xml2rfc library yet.  Other than that I think it's done.

R's,
John

---

From: Dave Cridland <[email-masked]>
Date: Wed, 21 May 2014 14:59:03 +0100

I've read through this; all looks good to me.

On 21 May 2014 04:33, John Levine <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 21 May 2014 10:05:44 -0700

In the third paragraph of section 4:

    "... or [email-masked] rather than [email-masked]."

This doesn't read right, to me at least.  I think I know what was intended here, but this looks like a cut/paste error crept in along the way.

--lyndon

---

From: "John Levine" <[email-masked]>
Date: 21 May 2014 18:20:31 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>This doesn't read right, to me at least.

The domain names aren't the same.

R's,
John

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 21 May 2014 12:17:01 -0700

> The domain names aren't the same.

Doh.  I guess I need a bigger terminal font :-P

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 22 May 2014 09:04:47 +0200

On Wednesday, May 21, 2014 7:05:44 PM CEST, Lyndon Nerenberg wrote:
> This doesn't read right, to me at least.  I think I know what 
> was intended here, but this looks like a cut/paste error crept 
> in along the way.

examp-one-e-dot-com rather than...

Not a terribly plausible typo, though. Might be better to use 
[email-masked] or [email-masked].

I've read through the draft and think it's fine.

Arnt

---

From: t.petch <[email-masked]>
Date: Thu, 22 May 2014 10:11:02 +0100

John

Some (mostly) editorial thought.

"that it will never accept email"
would prefer
"that it does not accept email"
ie you are making this RR an irrevocable commitment for all eternity
such that noone can ever change their mind and later accept mail - which
I find too much (I would not say 'currently does not' that simply sets
off too many hares)

/aserver/a server/

"with a 554 response"
since 5321.MailFrom is clearly a reference to RFC5321, then this must be
a reference to RFC554, no? I think you should add a [reference] here (I
know, you know, those on this list know, but we should be making it
clear for a wider audience)

/the perpetrators /The perpetrators /

"5321.MailFrom "
since 554 is not a reference to an RFC, then 5321 is not an RFC either,
no:-)  I think you should add a [reference] the first time this is used.

s.4 I think needs more work.

I imagine that the perpetrators of abusive mail will react.  Using a
non-existent return address is part of the abuse that they revel in; one
reaction could then be to switch to addresses that do not have any MX,
null or otherwise.  I am unsure where this then leads, but think it
needs consideration.  NULL MX benefits the good guys, but most of the
e-mail system is about the bad guys who look for a way to cause yet more
harm and this may give them ways of doing so.

Almost any RFC that has anything to do with an RR appears as an update
to RFC1035.  I think that this should too.

Should the copyright refer to material from pre-2008 or is Mark Delany
(whose material dates from 2005) happy to waive his rights?

Tom Petch

---

From: "John R Levine" <[email-masked]>
Date: 22 May 2014 09:31:23 -0400

Thanks, I'll work these in when I do the next draft.

In practice, these days spammers usually use return addresses in real 
domains, so that isn't a particularly strong factor either way.  The place 
where I see it being useful is more for people who don't know their own 
address and imagine that every domain name starts with www.

R's,
John

>> The domain names aren't the same.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 22 May 2014 16:11:39 +0200

It doesn't really matter whether it's useful. What you're doing is 
documenting current practice, whether sound or not.

(Unless it's past practice by now?)

Arnt

---

From: Tim Draegen <[email-masked]>
Date: Fri, 23 May 2014 10:39:58 -0400

> 	http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/

Grammar nits:
- 2nd sentence is missing a word:  "Unfortunately this means that the A/AAAA record is taken to be (the) mail server address even when that address does not accept mail."
- Section 2 "aserver" should be "a server".

Minor suggestions:
- Section 2 ends with "This document defines a NULL MX that will cause all mail delivery attempts to a domain to fail immediately."  Maybe tack on an extra sentence of "NULL MX performs this function without requiring domains to create SMTP listeners dedicated to preventing delivery attempts."
- Section 3 says NULL MX "offers many resource savings", but then lists only 1.  Suggested change (I'm replacing "It" with "An SMTP server"):
	An SMTP server can choose to reject email during the SMTP conversation if presented with an undeliverable 5321.MailFrom domain.  Similarly, when requested by an SMTP client to deliver a message to  an undeliverable RFC5321.RcptTo, the SMTP server can immediately report delivery failure.

Guidance for reply code when attempting to deliver to NULL MX domain?
There is a section 6 "Domains that do not send email", and it contains guidance for SMTP servers that reject mail due to MAIL FROM containing a domain that has a NULL MX record.  Should there be similar guidance on which reply code to propagate in the case where delivery is rejected due to attempting to deliver to a domain where NULL MX is present?  AFAICT this would mean a 550 reply, with bonus points if a mention to an enhanced status code of RFC 3463 section 3.2, X.1.2 "Bad destination system address" (http://tools.ietf.org/html/rfc3463#section-3.2) could be folded in.

=- Tim

---

From: Franck Martin <[email-masked]>
Date: Fri, 23 May 2014 19:28:02 -0500 (CDT)

This document does not seem to address where to send an abuse report for that domain?

if example.com is such domain with a null MX, I cannot email [email-masked] (which I think is required for all domains in theory, practice is different). The whois record may not contain that information either.

It would be interesting to tie the null mx with a record to where abuse should be sent. I'm not sure if it should be a separate draft an referred here, or if it should be mentionned here.

something like this could work

_abuse.example.com TXT "mailto:[email-masked];http://www.example.net/abuse"

Where mailto: would be a required.

Shall I propose some text?

---

From: "John Levine" <[email-masked]>
Date: 24 May 2014 04:11:41 -0000

>This document does not seem to address where to send an abuse report for that domain?

That is correct.  In that regard, it is consistent with every other
SMTP RFC over the past 30 years.

---

From: Ned Freed <[email-masked]>
Date: Fri, 23 May 2014 19:14:36 -0700 (PDT)

> This document does not seem to address where to send an abuse report for that

Why should it? Even if this was an important thing to be able to do - and I'm
quite skeptical that it is - it's an entirely separable problem.

> if example.com is such domain with a null MX, I cannot email
> [email-masked] (which I think is required for all domains in theory,

That's incorrect.  RFC 2142 only requires that abuse work for an
"organization's top level domain name" accept mail and have a corresponding
abuse mailbox. I interpret that to mean that this whole nullmx thing is
inappropriate for domains wanting to conform to this requirement.

There's also a requirement about supporting appropriate mailboxes for
the protocols that are actually associated with the domain name. So if
your domain has an email service associated with it various addresses
need to work, including abuse@. And once again the nullmx thing isn't
appropriate.

> It would be interesting to tie the null mx with a record to where abuse
> should be sent. I'm not sure if it should be a separate draft an referred here,
> or if it should be mentionned here.

We call those records MX records. And yes, that means you can't simultaneously
say "accept no mail" and "accepts abuse reports by doing so-and-so".

> Shall I propose some text?

I am strongly opposed to putting any such mechanism in this specification. If
you really think this is important enough to do, you can write a separate
document to do it.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 May 2014 12:41:19 -0400

My only thing about it is that its a bad title.  Its really not a 
"NULL" MX record. Its an explicitly defined MX record (not NULL) with 
a Preference value of zero.   I hope people don't read it wrong with 
NULL meaning no MX record is defined and this can translate to a NO 
MAIL operations or that a mail operation must have a MX record.

Section 5, however, is very clear and clean about the two requirements:

    - One MX RECORD only
    - Preference equal zero

If anything, update the abstract with one simple change to the last 
sentence to that interested readers will know exactly what it means 
upfront without the need to get into the details.

    ......  The NULL MX RR formalizes the existing
    mechanism by which a domain announces that it accepts no mail, which
    permits significant operational efficiencies, by creating a single
    MX record with a preference of Zero.

As we know NULL has a different meaning to C/C++ programmers and it 
might enforce code changes that take into account a returning count 
value versus a transversal/walk of a pointer to a MX array of sorted 
IP records.  When that returned pointer, i.e. pMX is NULL, then it 
could mean NO RECORDS to the implementation method.  Please don't tell 
me that is a WRONG or ODD.  Its a normal coding consideration.  Walks 
are cooler than having counts to some.

What I am saying this code could change:

    pMX = GetMXRecords(Target.Domain)
    if (!pMX) {
       return NO_MX_USE_A_FALLBALL;
    }
    ... walk the pMX pointer array for mail send attempt ....

to this where the DNS client API has to change to include a count:

    pMX = GetMXRecords(Target.Domain, &count)
    if (count == 0) {
       return NO_MX_USE_A_RR_FALLBACK;
    }
#ifdef SUPPORT_NULL_MX_PROPOSAL
    if (count == 1 && pMx[0].Preference == 0) {
       return SINGLE_MX_PREF_ZERO_NO_MAIL.
    }
#endif
    ... walk the pMX pointer array for mail send attempt ....

Thanks

--
HLS

-- 
HLS

---

From: Bill McQuillan <[email-masked]>
Date: Sat, 24 May 2014 15:40:48 -0700

> MAIL operations or that a mail operation must have a MX record.

So how about "NEGATIVE MX record". It seems to imply the explicit
denial of MX access to a domain rather than some kind of absence 
as implied by "NULL".

Just my 2¢

-- 
Bill McQuillan <[email-masked]>

---

From: "John Levine" <[email-masked]>
Date: 24 May 2014 23:43:36 -0000

>So how about "NEGATIVE MX record".

It's been called NULL MX since the first version of the draft in 2006,
and this is the first time anyone's complained about the name.  I'm
not inclined to change it.

---

From: Ned Freed <[email-masked]>
Date: Sat, 24 May 2014 21:03:44 -0700 (PDT)

> not inclined to change it.

And I am inclined to agreee. The name speaks to the nature of the record. I
don't view that as a bad thing.

				Ned