Subject: [DNSOP] "MX 0 ." standard way of saying "we don't do email" ?

From: Ondřej Surý <[email-masked]>
Date: Fri, 10 Apr 2009 09:57:14 +0200

Hi,

I have just encountered strange thing:

> > > security.eu.debian.org mail is handled by 0 .
> >
> > I am not sure if pointing MX record to other peoples zone is good idea.
> > And the root zone has it's own deal of DoS attack even without random
> > MXes pointing into it.
>
> "MX 0 ." is the standard way of saying "we don't do email".

Does anybody have an experience with that? How different MTAs behave?
How does bots behave? My opinion is that it can trigger IN A(AAA) requests
to a root zone in some cases, but there could be RFC I am not aware of which
defines this thing as "standard".

Ondrej
-- 
Ondrej Sury
technicky reditel/Chief Technical Officer
-----------------------------------------
CZ.NIC, z.s.p.o.  --  .cz domain registry
Americka 23,120 00 Praha 2,Czech Republic
mailto:[email-masked]  http://nic.cz/
sip:[email-masked] <[email-masked]> tel:+420.222745110
mob:+420.739013699     fax:+420.222745112
-----------------------------------------

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Apr 2009 10:10:50 +0200

On Fri, Apr 10, 2009 at 09:57:14AM +0200,
 Ond?ej Surý <[email-masked]> wrote 

> > "MX 0 ." is the standard way of saying "we don't do email".

Bullshit.

> How different MTAs behave?

Postfix does not ask the root, it stops after it had the MX:

Apr 10 10:08:48 aetius postfix/smtp[32380]: warning: valid_hostname: empty hostname
Apr 10 10:08:48 aetius postfix/smtp[32380]: warning: malformed domain name in resource data of MX record for security.eu.debian.org: 
Apr 10 10:08:48 aetius postfix/smtp[32380]: 0FA6094E35: to=<[email-masked]>, relay=none, delay=0.05, delays=0.04/0.01/0/0, dsn=5.4.4, status=bounced (Name service error for name=security.eu.debian.org type=MX: Malformed or unexpected name server reply)

> there could be RFC I am not aware of which defines this thing as
> "standard".

There is no standard way to say "I don't want to receive email"
(unfortunately).

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Apr 2009 18:29:52 +1000

In message <[email-masked]>, Stephane Bortzmeyer writes:
>  Ond?ej Sur=FD <[email-masked]> wrote =
> 
> Apr 10 10:08:48 aetius postfix/smtp[32380]: warning: valid_hostname: empty =
> hostname
> Apr 10 10:08:48 aetius postfix/smtp[32380]: warning: malformed domain name =
> in resource data of MX record for security.eu.debian.org: =
> 
> Apr 10 10:08:48 aetius postfix/smtp[32380]: 0FA6094E35: to=3D<doesnotexist@=
> security.eu.debian.org>, relay=3Dnone, delay=3D0.05, delays=3D0.04/0.01/0/0=
> , dsn=3D5.4.4, status=3Dbounced (Name service error for name=3Dsecurity.eu.=
> debian.org type=3DMX: Malformed or unexpected name server reply)
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

	This has been proposed in the past and is consistent with
	how SRV signals no support.  FUD has always shot it down.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: SM <[email-masked]>
Date: Fri, 10 Apr 2009 02:08:12 -0700

At 00:57 10-04-2009, OndÅ™ej SurÃ½ wrote:
> <http://security.eu.debian.org>security.eu.debian.org mail is handled by 0 .
> > >

It's called NULL MX.  There is an expired I-D 
about it at 
http://www.ietf.org/proceedings/05aug/IDs/draft-delany-nullmx-00.txt 
The attempt to standardize the practice was 
viewed as a bad idea by the DNSEXT WG.

>Does anybody have an experience with that? How different MTAs behave?

The MX RR will be ignored.  There will be an AAAA 
DNS request and a fallback to the A RR for 
security.eu.debian.org.  Newer versions of 
sendmail and Postfix will treat that MX RR as a 
bad MX and reject the message instead of retrying.

Regards,
-sm

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Apr 2009 09:53:46 -0400

At 2:08 -0700 4/10/09, SM wrote:

>It's called NULL MX.  There is an expired I-D about it at
>http://www.ietf.org/proceedings/05aug/IDs/draft-delany-nullmx-00.txt The
>attempt to standardize the practice was viewed as a bad idea by the DNSEXT WG.

There are three messages in the namedroppers archive about this.  One 
post says "send it to DNSOP." (So, it's about time. ;) )

But the draft really isn't about DNS.  It's about SMTP.

>The MX RR will be ignored.  There will be an AAAA DNS request and a fallback
>to the A RR for security.eu.debian.org.  Newer versions of sendmail and
>Postfix will treat that MX RR as a bad MX and reject the message instead
>of retrying.

...it's about SMTP...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 10 Apr 2009 16:23:37 +0200

Since it looks like it is already in use (at least in some MTAs) I am
willing to help
to standardize this. However I lack an experience what to do if there is no
smtp
working group. Should I send it to apps area ml, or to chairs of apps area?

It seems to be overkill to start whole wg just to standardize one draft,
isn't it?

Ondrej

On Fri, Apr 10, 2009 at 3:53 PM, Edward Lewis <[email-masked]> wrote:

> There are three messages in the namedroppers archive about this.  One post
> says "send it to DNSOP." (So, it's about time. ;) )
>

Ondrej

---

From: SM <[email-masked]>
Date: Fri, 10 Apr 2009 07:56:40 -0700

At 06:53 10-04-2009, Edward Lewis wrote:
>There are three messages in the namedroppers archive about 
>this.  One post says "send it to DNSOP." (So, it's about time. ;) )

And DNSOP said :-)

>But the draft really isn't about DNS.  It's about SMTP.

The question of NULL MX came up last year during a discussion about 
SMTP.  The SMTP question is about how to locate the target host.  As 
the proposal in the expired I-D has an operational impact on DNS 
operations, the SMTP folks will probably ask for the opinion of DNSOP.

Regards,
-sm

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Apr 2009 11:41:59 -0400

>>says "send it to DNSOP." (So, it's about time. ;) )

Until the post, no one brought this to the WG's attention.

(As an aside: I keep tabs on DNS, not SMTP.  If there's an issue in 
SMTP and no one brings it in front of the DNS lists, I'm not going to 
see the issue much less bring it to the DNS lists.)

>The question of NULL MX came up last year during a discussion about SMTP.
>The SMTP question is about how to locate the target host.  As the proposal
>in the expired I-D has an operational impact on DNS operations, the SMTP
>folks will probably ask for the opinion of DNSOP.

My opinion is that "it doesn't matter to DNS protocol and 
operations." No more so than, e.g., what ENUM does with the contents 
of NAPTR records has as an impact on the DNS.  (My opinion is not 
indicative of a consensus of the working group.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: SM <[email-masked]>
Date: Fri, 10 Apr 2009 13:04:39 -0700

At 07:23 10-04-2009, OndÅ™ej SurÃ½ wrote:
>Since it looks like it is already in use (at 
>least in some MTAs) I am willing to help
>to standardize this. However I lack an 
>experience what to do if there is no smtp

You can use the "historical" SMTP mailing list 
([email-masked]) to discuss about the 
draft.  You might want to ask DNSOP to review the draft first.

>It seems to be overkill to start whole wg just 
>to standardize one draft, isn't it?

In this case, yes.

>Until the post, no one brought this to the WG's attention.

This message ( 
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00944.html 
) and some other messages on the ietf-smtp 
mailing list could be read as a lack of support for the draft.

At 12:12 10-04-2009, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
>That list has been used for the development of RFC 5321 and it is
>going to be used for the desired Full Standard successor of it,

No, that's going to be done on another mailing list once the WG is chartered.

Regards,
-sm

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Apr 2009 16:19:03 -0400

At 13:04 -0700 4/10/09, SM wrote:

>) and some other messages on the ietf-smtp mailing list could be 
>read as a lack of support for the draft.

Don't confuse disinterest with disapproval. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: [email-masked]
Date: Fri, 10 Apr 2009 22:26:51 +0000

> Don't confuse disinterest with disapproval. ;)

	come on ed, just 'cause you disapproved of sub-typing TXT records...

--bill

---

From: Florian Weimer <[email-masked]>
Date: Sat, 11 Apr 2009 13:25:25 +0200

> The MX RR will be ignored.  There will be an AAAA DNS request and a
> fallback to the A RR for security.eu.debian.org.  Newer versions of
> sendmail and Postfix will treat that MX RR as a bad MX and reject the
> message instead of retrying.

Exim also treats the record as a "no SMTP service here" indication.  I
would even go so far to call this a de-facto standard (which just
hasn't been documented by the IETF).

(BTW, your user agent mangled Ondřej's name.)

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Apr 2009 12:20:14 -0700

On Apr 11, 2009, at 4:25 AM, Florian Weimer wrote:

>> sendmail and Postfix will treat that MX RR as a bad MX and reject  
>> the message instead of retrying.
>
> Exim also treats the record as a "no SMTP service here" indication.   
> I would even go so far to call this a de-facto standard (which just  

It would incorrect to describe MX records targeting the root as being  
a widely adopted standard to signal "No SMTP Service".

In the past, Paul Vixie raised concerns about even using root targets  
within SRV records, which has always been defined as a means to signal  
no service.  He said that his experience at the root had shown  
programmers should not be trusted to properly recognize root domains  
within SRV records.   In the case of SMTP, there was never a standard  
to properly ignore root targets.  A signaling scheme that shifts the  
signaling of no SMTP service responses to the root may prove  
detrimental.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Apr 2009 12:01:17 +1000

> signaling of no SMTP service responses to the root may prove  

	If a application is doing the wrong thing w.r.t. SRV records
	then fix the application.  The root servers can handle a A
	and AAAA queries for ".".  Most cache's will correctly
	negatively cache such responses.

	As for "MX 0 ." the sooner this gets defined as no SMTP
	service for this domain the better.  The cost for changing
	this is only every going to increase.

	Mark

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Apr 2009 23:54:20 -0700

On Apr 13, 2009, at 7:01 PM, Mark Andrews wrote:

> If a application is doing the wrong thing w.r.t. SRV records then  
> fix the application.  The root servers can handle a A	and AAAA  
> queries for ".".  Most cache's will correctly
> As for "MX 0 ." the sooner this gets defined as no SMTP service for  
> this domain the better.  The cost for changing this is only every  
> going to increase.

It may take years before a significant portion of SMTP servers  
recognize root domains as meaning no service.  An alternative would be  
to require MX records to assert SMTP service.  A positive assertion  
will not impose additional burdens on root servers, but will  
necessitate explicit DNS provisions to exchange SMTP messages.  With  
19 out of 20 messages being abusive and largely from compromised  
systems, requiring a domain to assert their intent to exchange public  
SMTP messages will encourage adoption without burdening root servers  
with strategies sure to generate extraneous traffic beyond their  
control.

SRV records have demonstrated the inability of roots to ensure  
applications mitigate extraneous traffic.  Expanding upon this failure  
seems sure to result in a growing number of wildcard MX records  
targeting roots.  Negative caching of randomly spoofed domains might  
not be an effective control.  It seems unwise to encourage a greater  
use of wildcard records that target roots.

-Doug

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Apr 2009 13:57:22 +0000

> > As for "MX 0 ." the sooner this gets defined as no SMTP service for  this
> > domain the better.  The cost for changing this is only every  going to
> > increase.
> 
> It may take years before a significant portion of SMTP servers  recognize
> root domains as meaning no service.

that would never happen.  most smtp initiators including embedded ones would
never be upgraded.  they'll just make ". IN A" queries trying to chase down
this MX's target.  a standard of this kind is a recipe for permanent increase
of worthless queries at the root servers.

> An alternative would be to require MX records to assert SMTP service.  A
> positive assertion will not impose additional burdens on root servers,
> but will necessitate explicit DNS provisions to exchange SMTP messages.
> With 19 out of 20 messages being abusive and largely from compromised
> SMTP messages will encourage adoption without burdening root servers with
> strategies sure to generate extraneous traffic beyond their control.

this also worries me since it makes good mail less deliverable as the cost
of stopping blowback, and it won't slow bad mail down at all.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 14 Apr 2009 10:30:48 -0400

On Apr 14, 2009, at 2:54 AM, Douglas Otis wrote:

> recognize root domains as meaning no service.  An alternative would  
> be to require MX records to assert SMTP service.  A positive  
> assertion will not impose additional burdens on root servers, but  
> will necessitate explicit DNS provisions to exchange SMTP messages.   
> With 19 out of 20 messages being abusive and largely from  
> compromised systems, requiring a domain to assert their intent to  
> exchange public SMTP messages will encourage adoption without  
> burdening root servers with strategies sure to generate extraneous  
> traffic beyond their control.
>
> applications mitigate extraneous traffic.  Expanding upon this  
> failure seems sure to result in a growing number of wildcard MX  
> records targeting roots.  Negative caching of randomly spoofed  
> domains might not be an effective control.  It seems unwise to  
> encourage a greater use of wildcard records that target roots.

I agree with Doug. The most reasonable course of action would be an  
IETF document, perhaps a BCP, that indicates SMTP transports should  
ONLY do MX lookups to find the mail server for a domain, and not fall  
back on A records. I'd endorse this, and would work on such a document  
if there were interest. The big question is whether it would be done  
in DNSOP, since it affects how DNS records are interpreted, or in the  
defunct SMTP group's list, since it affects how mail servers interpret  
DNS information.

I specifically do NOT agree with the "MX 0 ." approach, and do not see  
any reason why this would be a better solution than simply not having  
MX records at all. True, during implementation of an MX requirement,  
some portion of sites might have difficulty receiving email until they  
add an MX record. But adding MX records is a well-known process, and  
the effort for those domains that haven't bothered with them in the  
past will not be onerous.

I have used another solution as well, that being:

example.com.		IN	MX	nomail.example.com.
nomail.example.com.	IN	A	127.0.0.1

Those attempting to spam a domain that doesn't accept email will get  
upset with themselves, and not send packets to a server that's not  
interested. This does, sometimes, result in error messages for the  
sending server or their upstream relay, but keeps such alerts closer  
to the sender (who is likely a spammer anyway).

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Apr 2009 12:23:39 -0700

On Apr 14, 2009, at 6:57 AM, Paul Vixie wrote:

>> An alternative would be to require MX records to assert SMTP  
>> service.  A positive assertion will not impose additional burdens  
>> on root servers, but will necessitate explicit DNS provisions to  
>> exchange SMTP messages. With 19 out of 20 messages being abusive  
>> and largely from compromised systems, requiring a domain to assert  
>> their intent to exchange public SMTP messages will encourage  
>> adoption without burdening root servers with strategies sure to  
>> generate extraneous traffic beyond their control.
>
> this also worries me since it makes good mail less deliverable as  
> the cost of stopping blowback, and it won't slow bad mail down at all.

Reverse DNS could be placed in the same category.  Reverse DNS is not  
well supported on some networks.  Resulting DNS timeouts reduces MTAs  
resources and can lead to chronic unseen failures to connect.  This  
does cause the loss of good email.

A domain might make exceptions to a MUST HAVE MX RR rule at their MTA  
that is receiving messages from systems they monitor whenever adding  
an MX RR for the domain would otherwise attract undesired email  
abuse.  With a required MX RR convention, not publishing the MX record  
will offer greater protection from abuse for all hosts that publish IP  
address records in DNS.  As IPv6 becomes more widely used and Internet  
use becomes more diversified, more embedded devices and networks may  
be unable to endure the typical email abuse caused by backscatter or  
various checks made in an effort to determine whether a domain accepts  
the SMTP message traffic.

A required MX RR rule answers the question of SMTP exchange without  
burdening either uninvolved hosts or roots.  This rule may become a  
necessity in response to poorly considered tactics often used to  
defend MTAs from abuse.  Passing email's burdens onto otherwise  
uninvolved systems will not better defend the Internet.  Publishing an  
MX record would be a minor step toward increased protections and in  
ensuring email delivery which most domains have already taken.

-Doug

---

From: Todd Glassey <[email-masked]>
Date: Tue, 14 Apr 2009 12:25:23 -0700

Daniel Senie wrote:
> past will not be onerous
Daniel the reason is simple - because defining a MX 0 shows a specific 
intent. Having no MX record at all shows sloppy domain management and 
that there was no properly formed domain profile in the master public 
lookup's, i.e. DNS. By the way NEA desparately needs the ability to find 
a MX service in its operations IMHO.

So the idea is that there really isnt a need to make the world a better 
place for sloppy domain admin's, but that there is a need to properly 
define the positive and negative status of any domain element - 
including time servers (sorry couldnt help but sneak that one in).

Todd
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.238 / Virus Database: 270.11.57/2059 - Release Date: 04/14/09 14:52:00
>
>

---

From: Todd Glassey <[email-masked]>
Date: Tue, 14 Apr 2009 12:27:21 -0700

Douglas Otis wrote:
>> If a application is doing the wrong thing w.r.t. SRV records then fix 
>> the application.  The root servers can handle a A    and AAAA queries 
>> for ".".  Most cache's will correctly
> with strategies sure to generate extraneous traffic beyond their control.
>

Agreed. And Doug - this was a good succinct way of describing this 
requirement.

Todd

---

From: Florian Weimer <[email-masked]>
Date: Tue, 14 Apr 2009 21:37:43 +0200

* Paul Vixie:

> this MX's target.

Most embedded SMTP implementations do not perform mail routing. Those
who do have got an automated software update mechanism, thanks to
spam/AV filtering.

"MX 0 ." is quite widely deployed as far as the DNS is concerned, so
you root operators should already get the related A/AAAA traffic.
Theoretically, it shouldn't increase if there are more such MX records
because of the two-stage nature of the lookup.

---

From: SM <[email-masked]>
Date: Tue, 14 Apr 2009 12:40:06 -0700

Hi Daniel,
>defunct SMTP group's list, since it affects how mail servers interpret

I don't think you can override a Draft Standard with a BCP.  There 
was a discussion about the fallback to A/AAAA RRs (implicit MX) last 
year during a Last Call.  The consensus was to keep it in the SMTP 
standard.  I doubt that any further discussion on the subject will 
result in a different outcome.

Regards,
-sm

---

From: Daniel Senie <[email-masked]>
Date: Tue, 14 Apr 2009 15:43:54 -0400

On Apr 14, 2009, at 3:25 PM, Todd Glassey wrote:

>>>> As for "MX 0 ." the sooner this gets defined as no SMTP service  
>>>> for this domain the better.  The cost for changing this is only  
>>>> every going to increase.
>>>
>>> recognize root domains as meaning no service.  An alternative  
>>> would be to require MX records to assert SMTP service.  A positive  
>>> will necessitate explicit DNS provisions to exchange SMTP  
>>> messages.  With 19 out of 20 messages being abusive and largely  
>>> from compromised systems, requiring a domain to assert their  
>>> intent to exchange public SMTP messages will encourage adoption  
>>> without burdening root servers with strategies sure to generate  
>>> extraneous traffic beyond their control.
>>>
>> ONLY do MX lookups to find the mail server for a domain, and not  
>> fall back on A records. I'd endorse this, and would work on such a  
>> document if there were interest. The big question is whether it  
>> would be done in DNSOP, since it affects how DNS records are  
>> interpreted, or in the defunct SMTP group's list, since it affects  
>> how mail servers interpret DNS information.
>>
>> I specifically do NOT agree with the "MX 0 ." approach, and do not  
>> see any reason why this would be a better solution than simply not  
>> having MX records at all. True, during implementation of an MX  
>> requirement, some portion of sites might have difficulty receiving  
>> email until they add an MX record. But adding MX records is a well- 
>> known process, and the effort for those domains that haven't  
>> bothered with them in the past will not be onerous
> Daniel the reason is simple - because defining a MX 0 shows a  
> specific intent. Having no MX record at all shows sloppy domain  
> management and that there was no properly formed domain profile in  
> the master public lookup's, i.e. DNS. By the way NEA desparately  
> needs the ability to find a MX service in its operations IMHO.
>
> So the idea is that there really isnt a need to make the world a  
> better place for sloppy domain admin's, but that there is a need to  
> properly define the positive and negative status of any domain  
> element - including time servers (sorry couldnt help but sneak that  
> one in).

A related concern is the solution using "MX 0 ." then results in a  
further need, a wildcard in every zone, so that the base domain name  
is protected, and so that any hosts within the domain name are  
protected. So for example, you'd need an MX on example.com, but also a  
wildcard so that someone doing an MX lookup on www.example.com also  
gets told to get lost. So this is a further argument in my mind for a  
change in default SMTP transport behavior, as a zone with no MX  
records at all would indicate "don't send mail here." A zone with an  
MX on the domain name but nothing specified on a per-host basis or  
wildcard indicates "we take mail, only for email addresses  
@example.com". Again, this winds up being desirable as it should  
result in less traffic in the long run being sent to web servers and  
other servers that do not handle SMTP anyway.

As for the argument raised about IN-ADDR in relation to SMTP, there  
are already large email outfits that refuse email from hosts that do  
not have at least some result showing for a PTR lookup on the  
connecting IP address. Whether you like it or not, that's already in  
use, and it does block some spam.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 14 Apr 2009 15:49:06 -0400

> result in a different outcome.

See for example RFC 2644/BCP34, which updates RFC 1812, which is on  
standards track. There is precedent for a BCP to recommend alteration  
of the behavior of an earlier standard for the purposes of improving  
security, and/or taking into account newer information or  
observations. In the case of RFC2644/BCP34, the issue was that the  
requirement for the default handling of directed broadcasts turned out  
to be ill-advised.

As such I'm not convinced there is any issue with updating a standards  
document with a BCP, having written one that did precisely that.

---

From: Peter Koch <[email-masked]>
Date: Tue, 14 Apr 2009 23:43:20 +0200

> But the draft really isn't about DNS.  It's about SMTP.

I'd say this is not either/or, it's the use of DNS in another protocol.
It has to be addressed in a cross-wg or cross-area effort. Developing
a DNS view here is fine.

/* hat off */

The "solution" at hand has protocol ("additional section processing") and
operational implications but also touches upon general protocol design,
in particular how to interpret the absence of an RR or - from another angle -
how to specify absense of a service.  Someone already quoted
<http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00944.html>.

Fallback for RR types (try MX, then try A) looks attractive during the "phase in"
but increasingly bad later, because of exactly the problem that people are
facing with MX today: exactly that fallback makes it hard to tell whether
there should be _no_ mail service for that domain name.  Unfortunately
during the approval of RFC 5321, the explicit addition of AAAA fallback did
not really improve the situation.

The clean solution would involve some measurement regarding the volume of
non-spam (yeah, rathole) that is delivered through A-without-MX and some
willingness to move away from the fallback.  Of course, one might also
believe that redefining part of the ancient MX RR is much easier, especially
if you don't have to carry the DNS operational burden.

-Peter

---

From: Todd Glassey <[email-masked]>
Date: Tue, 14 Apr 2009 16:52:44 -0700

Daniel Senie wrote:
>>>> from compromised systems, requiring a domain to assert their intent 
>>>> to exchange public SMTP messages will encourage adoption without 
>>> email until they add an MX record. But adding MX records is a 
>>> well-known process, and the effort for those domains that haven't 
Yes - but this is an elegant way of sending telemetry to a client and 
that's why it works IMHO.

Todd

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 15 Apr 2009 02:23:48 -0400

Todd Glassey wrote:
>> back on A records. I'd endorse this, and would work on such a 
>> document if there were interest. The big question is whether it would 
>> be done in DNSOP, since it affects how DNS records are interpreted, 
>> or in the defunct SMTP group's list, since it affects how mail 
>> servers interpret DNS information.
>>
> lookup's, i.e. DNS. By the way NEA desparately needs the ability to 
> find a MX service in its operations IMHO.
>
> properly define the positive and negative status of any domain element 
"Proper" is in the eye of the beholder. I happen to think it's more 
"proper" for a NODATA response to an MX query to signal the absence of 
mail deliverability to a particular domain, which it unambiguously and 
with "specific intent" does if and when the A/AAAA failover is removed 
from the SMTP specification.

I'll note that the only subset of domain admins who would be negatively 
impacted by the removal of A/AAAA failover from SMTP, are those who are 
currently receiving mail by forcing clients to perform that failover. 
The polite and courteous thing is to provide MX records regardless, to 
save the mail clients one or more lookups. Is there a need to make the 
world a better place for impolite and/or discourteous domain admins?

I hereby register my support of removing A/AAAA failover from the SMTP 
specification (not that it carries much weight here on DNSOP, I 
realize), and my opposition to imbuing a certain MX target, namely, the 
root name, with a "special meaning" in this context, because a) these 
"special meaning" records use up resources that a NODATA response does 
not, and b) whenever the "special meaning" is -- as it is inexorably -- 
misinterpreted, or misunderstood, it results in more "junk" query 
traffic to the root nameservers.

-Kevin

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Apr 2009 16:31:14 +0200

In your previous mail you wrote:

=> it is an old problem, RFC 1846 tried to mitigate it...

Regards

[email-masked] (as a co-author of 1846).

---

From: Chris Thompson <[email-masked]>
Date: 15 Apr 2009 17:05:24 +0100

>hasn't been documented by the IETF).

However, it's maybe worth pointing out that Exim also provides support
for the alternative in which the absence of an MX record implies an
invalid mail domain. Specifically, the "mx_domains" option on a
dnslookup router specifies domains for which fallback to using an
address record should not occur (setting it to "*" would make that
apply universally). We have used this rule locally for domains under
cam.ac.uk for a very long time, which I am sure is why Philip Hazel
implemented the option in the first place.

Exim also provides the ability to use different retry rules in the
case when the target was found via an A or AAAA record, and these
are quite often used to give up (much) sooner on such deliveries.

-- 
Chris Thompson
Email: [email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Apr 2009 15:14:30 -0700

On Apr 14, 2009, at 12:40 PM, SM wrote:

> standard.

The RFC 282x update effort was to ensure compliance with dependency  
changes since their completion.  This basis excluded consideration of  
protocol changes.  The update did not close the book on changes to  
SMTP that would make it better behaved.  The Internet, and DNS in  
particular, will become unworkable whenever some protocol becomes a  
vector for undesired traffic then requires global changes to unrelated  
systems.  Defensive wildcard records targeting roots should not be  
published by all networks and systems not intended to handle the  
protocol becoming an undesired traffic vector.

One issue raised was to ensure SMTP independence of DNS when there is  
an MX record mandate.  For example, when hostname addresses are placed  
into host tables, MTAs should still exchange messages.  Most SMTP  
servers are doing extensive rule checking based upon several list  
types.  A rule that requires MX RRs MUST also include exceptions based  
upon information from other sources.

To help SMTP make a transition to an MX RR requirement, a new RFC  
related to DNS failure detection may thereby enable DNS related rule  
exceptions.  ADSP, about to be published, might include some of the  
needed language.

-Doug

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Apr 2009 17:51:10 +0100

On Tue, 14 Apr 2009, Peter Koch wrote:
> willingness to move away from the fallback.

In my experience the most common problematic messages with non-MX domains
are transactional email from web servers. The volume is not particularly
high, but the messages tend to be important to the recipients, and
problems tend to be difficult to fix if that requires assistance from the
webmaster. There's no chance that this situation will ever significantly
improve.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.