Re: Registration model, 2821bis-06
2008-04-03 17:02:34
Peter J. Holzer wrote:
the 974 fallback means that no MX
records + an A record implies authorization to deliver mail to that IPv4
address. it doesn't imply any authorization to deliver mail to any IPv6
address.
I think the 974 fallback does imply exactly that. It says so
explicitely:
| Where ever
| delivering a message is mentioned, all that is meant is that the
| mailer should do whatever it needs to do to transfer a message to a
| remote site, given a domain name for that site. (For example, an
| SMTP mailer will try to get an address for the domain name, which
| involves another query to the domain system, and then, if it gets an
| address, connect to the SMTP TCP port).
"whatever it needs to do ... given a domain name" and "an address for
the domain name" means to me "lookup both A and AAAA records" in a mixed
IPv4/IPv6 world.
Okay, maybe 974 does say that. But has been pointed out a couple of
times, the world has changed a lot since then. In this world of 90%
spam, clogged mail queues, and most hosts not being configured to
receive mail, I don't think it's appropriate anymore to assume that a
receiving host really really wants to get mail so badly (in the absence
of any explicit indication like an MX record) that the sending host
needs to do "whatever it needs to do" to get it there.
and of course 974 was obsoleted by 2821.
I understand the desire to get rid of the fallback. However, I don't
think that the wording in RFC 2821 can be reasonably extended to
"fallback for IPv4 only".
I think our job is to clearly specify what should work for the Internet
today, and what seems likely to work well in the future. I don't think
we're constrained to say only what text in old documents can be
"reasonably extended" to say.
If the fallback goes for AAAA records, I would very much like
to see it deprecated for A records, too (something like "clients MUST
lookup an A record, but SMTP service operators SHOULD NOT rely on this
behaviour and SHOULD add an explicit MX record").
I could see getting rid of support for fallback to A, but it would
require a sort of flag day. e.g. "sending MTAs SHOULD NOT fallback to A
after Dec 31, 2011 23:59:59 UTC". Though if we really wanted to do that
I think we'd be safely in "new document" territory as opposed to "wrap
up 2821bis" territory.
Keith
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Scope Creep, (continued)
Re: Scope Creep, Arnt Gulbrandsen
Re: Registration model, 2821bis-06, Keith Moore
Re: Registration model, 2821bis-06, Arnt Gulbrandsen
Re: Registration model, 2821bis-06, Peter J. Holzer
Re: Registration model, 2821bis-06,
Keith Moore <=
Re: Registration model, 2821bis-06, Frank Ellermann
Re: Registration model, 2821bis-06, Dave Crocker
Re: Registration model, 2821bis-06, Keith Moore
Re: Registration model, 2821bis-06, Arnt Gulbrandsen
Re: Registration model, 2821bis-06, Dave Crocker
Re: Registration model, 2821bis-06, Arnt Gulbrandsen
Re: Registration model, 2821bis-06, ned+ietf-smtp
Re: Registration model, 2821bis-06, John C Klensin
Re: Registration model, 2821bis-06, Arnt Gulbrandsen
Re: Registration model, 2821bis-06, Michael Storz
|
|
|