Mailing List Archive

RFC 7505 and domain 'list.cr.yp.to'
Hi Dan (or Russ, whoever is running the domain),

the MX Records, in detail it’s weight, ls flawed compared to John Levin’s RFC 7505:

host list.cr.yp.to
list.cr.yp.to mail is handled by 0 c.mx.list.cr.yp.to.


RFC 7505 (proposed standard):

1. Introduction


This document defines the No Service MX, informally called "null MX",
as a simple mechanism by which a domain can indicate that it does not
accept email.

….

If a domain has no MX records, senders will attempt to deliver mail
to the hosts at the addresses in the domain's A or AAAA records. If
there are no SMTP listeners at the A/AAAA addresses, message delivery
will be attempted repeatedly for a long period, typically a week,
before the sending Mail Transfer Agent (MTA) gives up. This will
delay notification to the sender in the case of misdirected mail and
will consume resources at the sender.

This document defines a null MX that will cause all mail delivery
attempts to a domain to fail immediately, without requiring domains
to create SMTP listeners dedicated to preventing delivery attempts.


Mail server complying with RFC 7505 will not be able to deliver mail to this domain (so my s/qmail does):

2015-09-01 07:48:38.457328500 new msg 28853882
2015-09-01 07:48:38.457359500 info msg 28853882: bytes 19080 from <feh@fehcom.de> qp 10301 uid 7005
2015-09-01 07:48:38.580199500 starting delivery 120: msg 28853882 to remote qmail@list.cr.yp.to
2015-09-01 07:48:38.580202500 status: local 0/10 remote 1/100
2015-09-01 07:48:40.395327500 new msg 28853881
2015-09-01 07:48:40.395354500 info msg 28853881: bytes 19080 from <feh@fehcom.de> qp 10300 uid 7005
2015-09-01 07:48:40.529473500 starting delivery 121: msg 28853881 to remote michael@hudsonstreet.us
2015-09-01 07:48:40.529477500 status: local 0/10 remote 2/100
2015-09-01 07:48:40.974605500 delivery 120: deferral: _Sorry,_I_couldn't_find_any_host_named:_list.cr.yp.to._(#4.1.2)/
2015-09-01 07:48:40.974642500 status: local 0/10 remote 1/100


As workaround; I included list.cr.yp.to in smtproutes:

list.cr.yp.to:c.mx.list.cr.yp.to


best regards.
—eh.

---
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: 7E4034BE
Re: RFC 7505 and domain 'list.cr.yp.to' [ In reply to ]
On Tuesday 01 Sep 2015 10:16:23 Erwin Hoffmann wrote:
> Hi Dan (or Russ, whoever is running the domain),
>
> the MX Records, in detail it’s weight, ls flawed compared to John Levin’s
> RFC 7505:
>
> host list.cr.yp.to
> list.cr.yp.to mail is handled by 0 c.mx.list.cr.yp.to.
>
>
> RFC 7505 (proposed standard):
>
> 1. Introduction
>
>
> This document defines the No Service MX, informally called "null MX",
> as a simple mechanism by which a domain can indicate that it does not
> accept email.
>
> ….
>
> If a domain has no MX records, senders will attempt to deliver mail
> to the hosts at the addresses in the domain's A or AAAA records. If
> there are no SMTP listeners at the A/AAAA addresses, message delivery
> will be attempted repeatedly for a long period, typically a week,
> before the sending Mail Transfer Agent (MTA) gives up. This will
> delay notification to the sender in the case of misdirected mail and
> will consume resources at the sender.
>
> This document defines a null MX that will cause all mail delivery
> attempts to a domain to fail immediately, without requiring domains
> to create SMTP listeners dedicated to preventing delivery attempts.
>
>
> Mail server complying with RFC 7505 will not be able to deliver mail to this
> domain (so my s/qmail does):
>
> 2015-09-01 07:48:38.457328500 new msg 28853882
> 2015-09-01 07:48:38.457359500 info msg 28853882: bytes 19080 from
> <feh@fehcom.de> qp 10301 uid 7005 2015-09-01 07:48:38.580199500 starting
> delivery 120: msg 28853882 to remote qmail@list.cr.yp.to 2015-09-01
> 07:48:38.580202500 status: local 0/10 remote 1/100
> 2015-09-01 07:48:40.395327500 new msg 28853881
> 2015-09-01 07:48:40.395354500 info msg 28853881: bytes 19080 from
> <feh@fehcom.de> qp 10300 uid 7005 2015-09-01 07:48:40.529473500 starting
> delivery 121: msg 28853881 to remote michael@hudsonstreet.us 2015-09-01
> 07:48:40.529477500 status: local 0/10 remote 2/100
> 2015-09-01 07:48:40.974605500 delivery 120: deferral:
> _Sorry,_I_couldn't_find_any_host_named:_list.cr.yp.to._(#4.1.2)/ 2015-09-01
> 07:48:40.974642500 status: local 0/10 remote 1/100
>
>
> As workaround; I included list.cr.yp.to in smtproutes:
>
> list.cr.yp.to:c.mx.list.cr.yp.to

Not quite: The RFC states that the label should be "." as well as the weight
being 0, so the DNS record for list.cr.yp.to doesn't count as a null MX; see
section 3 of the RFC,

" To indicate that a domain does not accept email, it advertises a
single MX RR (see Section 3.3.9 of [RFC1035]) with an RDATA section
consisting of preference number 0 **and** a zero-length label, written in
master files as ".", as the exchange domain, to denote that there
exists no mail exchanger for a domain."

cheers,

Andrew.
--
====================================================================
* Custom email solutions * Systems Administration * Networking
http://www.acrconsulting.co.uk/email/qmail.html
====================================================================
Re: RFC 7505 and domain 'list.cr.yp.to' [ In reply to ]
Hi Andrew,

thanks for your response.

I need to take that into consideration for s/qmail.

regards.
—eh.

Am 01.09.2015 um 11:04 schrieb Andrew Richards <ar-djblists@acrconsulting.co.uk>:

> On Tuesday 01 Sep 2015 10:16:23 Erwin Hoffmann wrote:
>> Hi Dan (or Russ, whoever is running the domain),
>>
>> the MX Records, in detail it’s weight, ls flawed compared to John Levin’s
>> RFC 7505:
>>
>> host list.cr.yp.to
>> list.cr.yp.to mail is handled by 0 c.mx.list.cr.yp.to.
>>
>>
>> RFC 7505 (proposed standard):
>>
>> 1. Introduction
>>
>>
>> This document defines the No Service MX, informally called "null MX",
>> as a simple mechanism by which a domain can indicate that it does not
>> accept email.
>>
>> ….
>>
>> If a domain has no MX records, senders will attempt to deliver mail
>> to the hosts at the addresses in the domain's A or AAAA records. If
>> there are no SMTP listeners at the A/AAAA addresses, message delivery
>> will be attempted repeatedly for a long period, typically a week,
>> before the sending Mail Transfer Agent (MTA) gives up. This will
>> delay notification to the sender in the case of misdirected mail and
>> will consume resources at the sender.
>>
>> This document defines a null MX that will cause all mail delivery
>> attempts to a domain to fail immediately, without requiring domains
>> to create SMTP listeners dedicated to preventing delivery attempts.
>>
>>
>> Mail server complying with RFC 7505 will not be able to deliver mail to this
>> domain (so my s/qmail does):
>>
>> 2015-09-01 07:48:38.457328500 new msg 28853882
>> 2015-09-01 07:48:38.457359500 info msg 28853882: bytes 19080 from
>> <feh@fehcom.de> qp 10301 uid 7005 2015-09-01 07:48:38.580199500 starting
>> delivery 120: msg 28853882 to remote qmail@list.cr.yp.to 2015-09-01
>> 07:48:38.580202500 status: local 0/10 remote 1/100
>> 2015-09-01 07:48:40.395327500 new msg 28853881
>> 2015-09-01 07:48:40.395354500 info msg 28853881: bytes 19080 from
>> <feh@fehcom.de> qp 10300 uid 7005 2015-09-01 07:48:40.529473500 starting
>> delivery 121: msg 28853881 to remote michael@hudsonstreet.us 2015-09-01
>> 07:48:40.529477500 status: local 0/10 remote 2/100
>> 2015-09-01 07:48:40.974605500 delivery 120: deferral:
>> _Sorry,_I_couldn't_find_any_host_named:_list.cr.yp.to._(#4.1.2)/ 2015-09-01
>> 07:48:40.974642500 status: local 0/10 remote 1/100
>>
>>
>> As workaround; I included list.cr.yp.to in smtproutes:
>>
>> list.cr.yp.to:c.mx.list.cr.yp.to
>
> Not quite: The RFC states that the label should be "." as well as the weight
> being 0, so the DNS record for list.cr.yp.to doesn't count as a null MX; see
> section 3 of the RFC,
>
> " To indicate that a domain does not accept email, it advertises a
> single MX RR (see Section 3.3.9 of [RFC1035]) with an RDATA section
> consisting of preference number 0 **and** a zero-length label, written in
> master files as ".", as the exchange domain, to denote that there
> exists no mail exchanger for a domain."
>
> cheers,
>
> Andrew.
> --
> ====================================================================
> * Custom email solutions * Systems Administration * Networking
> http://www.acrconsulting.co.uk/email/qmail.html
> ====================================================================
>

---
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: 7E4034BE
Re: RFC 7505 and domain 'list.cr.yp.to' [ In reply to ]
Thus said Erwin Hoffmann on Tue, 01 Sep 2015 10:16:23 +0200:

> RFC 7505 (proposed standard):

What exactly is the purpose, not to mention utility and usefulness, of a
null MX? Yes, I understand that previous RFCs indicate that if no MX is
found that a last ditch effort should be made if there is an A record
found for the name.

So what? So someone sends a message to a domain for which there is
really no legitimate mail server (e.g. the A record is a web server that
doesn't handle email). They will eventually get a bounce message or some
kind of indication that the message has not been delivered anywhere.

So, exactly what kind of problem does null MX solve?

Instead, it would seem to introduce yet more lame behavior into SMTP.

> This document defines a null MX that will cause all mail delivery
> attempts to a domain to fail immediately, without requiring domains
> to create SMTP listeners dedicated to preventing delivery attempts.

Is there honestly anyone setting up ``SMTP listeners dedicated to
preventing delivery attempts'' because they are worried that someone who
might just try to guess an address was wrong? E.g. if someone mistakenly
sends an email to webserveronly.dom they will eventually learn that they
made a mistake. Why anyone would think they need to setup an SMTP daemon
simply to reject said messages seems strange to me.

Andy
--
TAI64 timestamp: 4000000055e5ad83