Subject: [apps-discuss] draft-delany-nullmx-01

From: "John Levine" <[email-masked]>
Date: 11 Dec 2013 02:18:08 -0000

Mark Delany originally wrote this draft back in 2005.  I resuscitated
it with his consent in July.  I would like appsawg to adopt it and,
assuming you don't hate it, publish it on the standards track.

The point of null MX is really simple: if a domain does not receive
mail, it publishes this DNS record to say so:

	blah.example MX 0 .

Currently, if a domain has an A or AAAA record but no MX, there's no
way to tell whether or not the A is supposed to be a default MX, so
MTAs will hammer on it for a week before giving up.  This prevents the
hammering, and allows sending MTAs to return a useful error message
right away rather than an ambiguous message after a week.

I believe people have been using this informally since Mark published
the original draft in 2005, and I haven't heard any bad reports.  Note
that SPF -all means I send no mail, which although highly correlated
with I receive no mail, is not the same thing.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Dec 2013 22:18:24 -0500

> with I receive no mail, is not the same thing.

I think the fallback to A is too prevalent to be ignored. I also 
thought the "BCP" was:

            No MX ---> Single Shot A record (if any) attempt.

That has been our implementation (as a default enabled feature) since 
day one and I recall past discussions (in IETF-SMTP) where others has 
stated they also followed a similar "No MX, Try A once" logic as well. 
This avoided or minimized the "hammering" to just one attempt before a 
bounce is initiated.

Anyway, I am willing to consider support a logic for MX preference 
equal zero means no transaction SHOULD be attempted.  Actually, what 
it SHOULD technically mean is its not included in the total 
grouping/sorting of MX records.  This will allow for backward 
compatibility for the traditional NO MX records yields a Try A record 
fallback logic (local policy dictating how many tries are attempted).

-- 
HLS

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 10 Dec 2013 23:15:34 -0500

> mail, it publishes this DNS record to say so:

I think having the "." as server name is not a good idea as it is always possible that an A or AAAA record
will show up there. 
Joe Abley and I proposed this some time back; 
http://tools.ietf.org/html/draft-jabley-sink-arpa-01

That proposal needs to be updated to follow RFC6761 to register a reserved name in .arpa for this 
purpose like "no-mail.arpa."

	blah.example. MX 0 no-mail.arpa. 

> with I receive no mail, is not the same thing.

Other than that minuscule point of what the name is this is a good draft. 

	Olafur

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2013 04:29:12 -0000

> I think having the "." as server name is not a good idea as it is
> always possible that an A or AAAA record >will show up there. 

An A record at the root?  You must be kidding.

R's,
John

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 10 Dec 2013 23:38:42 -0500

> An A record at the root?  You must be kidding.

In ICANN's world nothing is impossible. 

But more seriously 

as the draft is written it takes mail server 3 DNS queries to assert there is no place to send 
mail too.

With a non-existing domain the mail server only needs one query. 

You only get a NXDOMAIN when there is NOTHING at the name in question 
thus a lookup for "." A currently gets back RCODE=0 (no error) and empty answer section 

	Olafur

---

From: "John R Levine" <[email-masked]>
Date: 10 Dec 2013 23:45:30 -0500

> In ICANN's world nothing is impossible.

Given the foofarrah about dotless domains, I'm not too worried about it.

> as the draft is written it takes mail server 3 DNS queries to assert there is no place to send

Huh?  The client does one lookup for the MX, and it's done.

I suppose that MTAs that don't understand this hack might try to look for 
a A record at the root, but the point is that with this as a standard,
MTAs recognize it as a flag so they can immediately fail the message.  I 
checked a while ago and a lot already do.

R's,
John

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 11 Dec 2013 08:45:32 +0100 (CET)

On Tue, 10 Dec 2013, Hector Santos wrote:

> I think the fallback to A is too prevalent to be ignored. I also thought the 
> "BCP" was:
>
> That has been our implementation (as a default enabled feature) since day one 
> and I recall past discussions (in IETF-SMTP) where others has stated they 
> also followed a similar "No MX, Try A once" logic as well. This avoided or 
> minimized the "hammering" to just one attempt before a bounce is initiated.

But this is also the know cause of a mumber of failed deliveries, which 
instead was fully legitimate: many embedded (expecially into web site 
scripts) SMTP small servers do that... and when they meet a graylist, 
fail!

> Anyway, I am willing to consider support a logic for MX preference equal zero 
> means no transaction SHOULD be attempted.  Actually, what it SHOULD 
> technically mean is its not included in the total grouping/sorting of MX 
> records.  This will allow for backward compatibility for the traditional NO 
> MX records yields a Try A record fallback logic (local policy dictating how 
> many tries are attempted).

I agree... MX 0 is likely a better "legalization" of a practice...
>
> -- 
> HLS
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Dec 2013 00:49:00 -0800

Separate from the specific mechanism chosen, does the working group want to
put time into producing a document that proposes a standard way of saying
"We do not accept mail?"

We could use this document as a starting point for such work if the WG
thinks it's appropriate.  If the answer to the first question is "yes" but
the second is "no", does anyone have an alternative proposal?

-MSK, APPSAWG co-chair

On Tue, Dec 10, 2013 at 11:45 PM, Claudio Allocchio <
[email-masked]> wrote:

>> I think the fallback to A is too prevalent to be ignored. I also thought
>> the "BCP" was:
>>
>> That has been our implementation (as a default enabled feature) since day
>> one and I recall past discussions (in IETF-SMTP) where others has stated
>> they also followed a similar "No MX, Try A once" logic as well. This
>> avoided or minimized the "hammering" to just one attempt before a bounce is
>> initiated.
>>
>
> scripts) SMTP small servers do that... and when they meet a graylist, fail!
>
>
>  Anyway, I am willing to consider support a logic for MX preference equal
>> zero means no transaction SHOULD be attempted.  Actually, what it SHOULD

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 11 Dec 2013 19:00:13 +0900

> put time into producing a document that proposes a standard way of saying

Having something like that seems to make sense.

> the second is "no", does anyone have an alternative proposal?

Because of the nature of this WG, I'd prefer to work on improving 
specific drafts rather than starting from scratch. But I'm not enough of 
an email expert to say that this is the one and only right approach.

Regards,   Martin.

> -MSK, APPSAWG co-chair
>
>
>
> On Tue, Dec 10, 2013 at 11:45 PM, Claudio Allocchio<

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Dec 2013 11:16:21 +0000

John Levine <[email-masked]> wrote:
> the original draft in 2005, and I haven't heard any bad reports.

Exim has implemented these semantics since version 4.31 released in March
2004. This was partly a side-effect of its experimental support for using
SRV records to route mail which shares code with its MX handling, so
Exim's MX handling gained SRV-style no-service semantics.

Here's a quick sample of domains which are using MX 0 . - it seems to be
popular with a certain class of fraudulent domains...

Aenean.com
account2.com
adsl.xs4all.nl
ahoo.com
allweb.org
alyahoo.com
apsn.com
ayhoo.com
bedfordconservatives.com
bricon.com
cbnnig.com
cdmnet.com
cex.net
cis.com
complexmatters.com
customsoffice.com
dahoo.com
daymassage.com
dci.iran.com
djd.net
dominio.com
elit.org
eqp.net
erepairs.com
fcn.net
fhy.org
galacticgalaxy.com
glk.com
glotrade.com
gmil.com
gtat.net
hjw.net
hotmil.com
inmovie.com
johnnywatts.com
karm.net
kellerhewitt.com
le.net
leq.net
loveki.com
lsfco.com
lxg.org
mailadministrator.com
mailoman.com
mailyahoo.com
majjo.com
meupainel.com
microlabtech.com
missionnews.com
mnmail.com
ndyou.com
nru.net
ntinternet.com
orci.org
otrebor.com
payqal.com
prioritycatalyst.com
repairbooking.com
rfm.net
senders.org
tbranch.com
tradelinkers.com
uqs.org
vel.org
webmailprovider.com
yaho.com
yahoo.com.es
yahoo.net
yahooi.com
yahoolotto.com
yahoomail.com
yahooo.com
yanhoo.com
yashoo.com
yayhoo.com
yhaoo.com
yhoo.com
yooho.com

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Dec 2013 11:25:02 +0000

Olafur Gudmundsson <[email-masked]> wrote:
>
> I think having the "." as server name is not a good idea

It is a good choice because it matches what is already specified for SRV
records and there has been running code working this way for nearly 10
years.

> as it is always possible that an A or AAAA record will show up there.

Haha.

Tony.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Dec 2013 08:51:00 -0800

On 12/11/2013 12:49 AM, Murray S. Kucherawy wrote:
> Separate from the specific mechanism chosen, does the working group want
> to put time into producing a document that proposes a standard way of
> saying "We do not accept mail?"
>
> thinks it's appropriate.  If the answer to the first question is "yes"
> but the second is "no", does anyone have an alternative proposal?

The proposed mechanism eliminates a relevant class of wasted mail 
traffic -- /prior to transmission across the open Internet/.  The 
mechanism is quite simple, quite inexpensive for the domain owner, and 
essentially free for the host attempting transmission.

It's unlikely anyone is going to propose a better mechanism for handling 
this class of traffic.

The draft is straightforward, seems to be well-structured and reasonably 
thorough.  It needs wordsmithing, but probably does not need massive 
technical enhancement.

If that doesn't make it an excellent, direct candidate for the apps wg, 
I can't imagine what does.

Besides that, any IETF-related draft that might be useful and is only 5 
pages long ought to be published, just to show we are capable of 
promoting short documents...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Wed, 11 Dec 2013 09:20:03 -0800 (PST)

> put time into producing a document that proposes a standard way of saying

I'm in favor of it.

> the second is "no", does anyone have an alternative proposal?

I think the current proposal needs to be the starting point. I'll add that
from what I've seen change for change's sake, while never a good idea,
is particularly likely to backfire when it comes to mechanisms like this.

				Ned

---

From: Dave Cridland <[email-masked]>
Date: Wed, 11 Dec 2013 17:32:48 +0000

> saying "We do not accept mail?"
Yes.

> the second is "no", does anyone have an alternative proposal?
As Dave Crocker says, it's a useful draft and only 5 pages, and as Tony
Finch says, this one is essentially a parallel to SRV, and deployed already.

I'm in support of adopting.

Two comments on the draft as-is:

Second paragraph of §4 suggests that if there are multiple MX RRs including
the NULL MX record, then the NULL MX record is treated as any other; this
seems unlikely to be actually desirable. Instead, I suggest that it is
ignored, with a note that if it is merely treated as any other MX RR, it is
unlikely to cause significant damage. I'd be fascinated to know what Exim
does currently.

The Security Considerations in §6 might point out that a single NULL MX RR
might be spoofable more easily via poison cache style attacks - it's not
entirely clear to me that this would cause more problems than any other DNS
poisoning attack based around MX records, but my gut feeling is that it's a
slightly softer target, and could be less immediately identifiable.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Dec 2013 17:53:18 +0000

On 11/12/2013 08:49, Murray S. Kucherawy wrote:
> Separate from the specific mechanism chosen, does the working group 
> want to put time into producing a document that proposes a standard 
> way of saying "We do not accept mail?"
Yes.

> thinks it's appropriate.
Yes.

> If the answer to the first question is "yes" but the second is "no", 
> does anyone have an alternative proposal?

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Dec 2013 14:14:32 -0500

On 12/11/2013 3:49 AM, Murray S. Kucherawy wrote:
> thinks it's appropriate.� If the answer to the first question is "yes"

The beauty of the NULLMX proposal is that it would fit in with 
existing MX lookups logic for mail senders. The lookup discovery logic 
exist.  It would be relatively easy to add logic to exclude the MX=0 
record from the MX grouping/sorting required to be done already and 
also use this mx=0 condition to "skip" the outbound transaction or end 
the attempts so that a bounce is started.

But in general, I agree with a consideration for a new all 
encompassing, flexible, single source, domain-based receiver policy 
discovery protocol that will combine many (and future) receiver 
attributes concepts along these lines.

Here are other server/receiver discovery attributes that can be very 
useful leveraging information for mail senders:

   - We do not accept mail.

   - We only accept authenticated mail (no public anonymous mail).

   - We accept anonymous mail during X to Y hours.
     Z hours reserved for private transactions.
     (This allows for the DMA market to coexist during controlled hours).

   - This service requires ALL transactions to be DKIM signed.

   - We don't allow mail over X MB/GB size.

   - We will perform SPF checks.

   - WE WILL REJECT ON SPF -ALL policy Results!

   - We will perform DKIM checks.

   - We will do greylisting.

   - We will limit connections to X clients.

   - WE WILL REJECT ON ADSP reject policy results.

   - WE WILL REJECT ON DMARC reject policy results.

   - WE SUPPORT RRVS reject results.

and so on.  Such a flexible server/receiver protocol will be a major 
benefit to the internet mail framework to help reduces all sorts of 
overheads, waste and also better secure security requirements in 
transactions. It can also assist in raising the email-bar and 
migration to stronger enforcement policies.

The 2006 DSAP [1] draft explored the idea of allowing companies to 
query customer's email address receiver policies for possible DKIM 
signing policies and restrictions.  So if a BANK required its eBanking 
users to have a DKIM-checking email address receiver, it can double 
check this strong transaction requirement and if also a vendor email 
domain address that does offer DKIM support.

Same idea applies for other conditions we want the receivers to have 
today.

Certainly, we can do much of this within the existing ESMTP framework 
(expose Receiver capabilities during the EHLO response).

-- 
HLS

[1] DKIM Signature Authorization Protocol
     http://tools.ietf.org/html/draft-santos-dkim-dsap-00

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Dec 2013 15:35:36 -0800

I don't believe we can do a formal call for adoption until we have at least
a couple of our current documents submitted to the IESG.  In the past we've
received complaints when we've had a docket of active WG documents at the
current size, so we can't enlarge it now.

Perhaps this is incentive for people interested in draft-delany-nullmx to
submit reviews for the other documents that are waiting for them, so that
we can get them out of the way... :-)

-MSK

On Wed, Dec 11, 2013 at 9:53 AM, Alexey Melnikov
<[email-masked]>wrote:

>  If the answer to the first question is "yes" but the second is "no", does
>> anyone have an alternative proposal?
>>
>
>

---

From: Franck Martin <[email-masked]>
Date: Wed, 11 Dec 2013 18:57:48 -0600 (CST)

----- Original Message -----
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Sent: Tuesday, December 10, 2013 6:18:08 PM
> Subject: [apps-discuss] draft-delany-nullmx-01
> 

My worry is that this structure indicates that the domain name may be sending emails. It is not uncommon to check if a domain has a A, AAAA or MX record before accepting email. If the domain cannot receive, then how do you handle replies?

http://svn.apache.org/repos/asf/spamassassin/branches/3.2/lib/Mail/SpamAssassin/Plugin/DNSEval.pm
---
sub check_dns_sender {
...
 dbg("dns: checking A and MX for host $host");

 $pms->do_dns_lookup($rule, 'A', $host);
 $pms->do_dns_lookup($rule, 'MX', $host);
...
}
---

I think the draft needs to be extended to indicate, that this also means the domain is not sending any emails.

---

From: "John R Levine" <[email-masked]>
Date: 11 Dec 2013 20:05:30 -0500

> My worry is that this structure indicates that the domain name may be sending emails. It is not uncommon to check if a domain has a A, AAAA or MX record before accepting email. If the domain cannot…

Um, if you'd read the draft, you'd know that it specifically says that it 
makes no assertions about whether a domain sends mail.

We already have SPF -all to say a domain sends no mail.

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

---

From: Franck Martin <[email-masked]>
Date: Wed, 11 Dec 2013 18:26:03 -0800

On Dec 11, 2013, at 5:05 PM, John R Levine <[email-masked]> wrote:

> Um, if you'd read the draft, you'd know that it specifically says that it makes no assertions about whether a domain sends mail.
> 
If you read my email, this is my point, adding an MX to a domain breaks the more common check to see if a receiver should accept emails from such domain.

To fix this situation, this draft needs to say, you should not accept emails from such domain.

---

From: "John R Levine" <[email-masked]>
Date: 11 Dec 2013 21:28:17 -0500

> To fix this situation, this draft needs to say, you should not accept emails from such domain.

I disagree, but first let's see if the WG adopts the draft before we start 
arguing about what it should say.

Regards,

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 12 Dec 2013 07:20:38 +0000

I agree with Murray here

/Salvatore

On Dec 12, 2013, at 12:35 AM, "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
 wrote:

I don't believe we can do a formal call for adoption until we have at least a couple of our current documents submitted to the IESG.  In the past we've received complaints when we've had a docket of active WG documents at the current size, so we can't enlarge it now.

Perhaps this is incentive for people interested in draft-delany-nullmx to submit reviews for the other documents that are waiting for them, so that we can get them out of the way... :-)

-MSK

On Wed, Dec 11, 2013 at 9:53 AM, Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:
On 11/12/2013 08:49, Murray S. Kucherawy wrote:
Separate from the specific mechanism chosen, does the working group want to put time into producing a document that proposes a standard way of saying "We do not accept mail?"
Yes.

We could use this document as a starting point for such work if the WG thinks it's appropriate.
Yes.

If the answer to the first question is "yes" but the second is "no", does anyone have an alternative proposal?

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Dec 2013 11:34:27 +0000

> unlikely to cause significant damage. I'd be fascinated to know what Exim

Exim treats them like any other MX record unless there is only one. (Same
as its SRV logic.) I don't think it makes much difference either way,
though perhaps there should be a requirement to suppress the target host
address lookups whenever the target is ".". (But I note that RFC 2782 does
not have such a requirement for SRV records, except when there is a single
null SRV.)

> might be spoofable more easily via poison cache style attacks

Feh, just deploy DNSSEC already! :-)

Tony.

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Dec 2013 11:38:08 +0000

Franck Martin <[email-masked]> wrote:
>
> My worry is that this structure indicates that the domain name may be
> sending emails. It is not uncommon to check if a domain has a A, AAAA or
> MX record before accepting email.

Isn't this covered by section 5, which says that if you send mail from a
domain with a null MX, it probably won't be accepted. (Exim will certainly
reject it.)

Tony.

---

From: "John Levine" <[email-masked]>
Date: 12 Dec 2013 15:41:05 -0000

>domain with a null MX, it probably won't be accepted. (Exim will certainly

Everyone agrees that as a matter of good practice, any domain that
sends mail should also receive mail, if only to collect the bounces.

But no RFC has ever *said* that explicitly.  It'd be a change to the
underlying spec.  Perhaps it's one we will agree to make, but it's not
the kind of thing to do casually.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Dec 2013 15:46:56 +0000

> the kind of thing to do casually.

I view a null MX record as saying "this is not a mail domain", and that
implies that it can't receive mail and shouldn't be used to send mail,
just as if you tried to use nxdomain.example.com as a mail domain. The new
thing is the ability to say something isn't a mail domain; there is no
change to the rest of the service model.

Tony.

---

From: "Walter H." <[email-masked]>
Date: Thu, 12 Dec 2013 21:16:57 +0100

> sends mail should also receive mail, if only to collect the bounces.
Why do you need an MX record?

if the zone file of the domain example.com contains one host called www,
then you can email to  [email-masked] without the need of any 
MX record ...

shouldn't there be the reverse, that in case you have a null MX you are 
not allowed to be the sender of any email?

Walter