ietf
[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-24 15:40:55
FWIW, my opinion is that if you want to accept incoming mail via IPv6, 
you need to advertise one or more MX records that point to ipv6-capable 
hosts.

Treating A records (in the absence of MX records) as "implicit MX" 
records was a hack needed to avoid forcing everyone to advertise an MX 
record or lose incoming mail, back in days where many sites didn't even 
support DNS very well, much less MX.

We don't need such a hack today because nobody today can expect to 
reliably receive Internet mail using only an IPv6 address.  For the 
foreseeable future, if you want to reliably receive incoming email, 
you're going to need an MX server on the public IPv4 Internet. 
Similarly if you want to reliably send outgoing email, you're going to 
need an SMTP relay on the IPv4 Internet.  Any ability to use IPv6 is 
just an optimization.

There are at least two reasons why it's better to not treat AAAA as an 
implicit MX:

1. fewer DNS lookups for the case where a host doesn't want to receive mail
2. immediate failure of mail sent to domain names that don't advertise 
either an MX or A record

(I'm a bit more dubious about the anti-spam argument.)


Also, I think that RFC2821bis is a fine place to fix this.  Putting the 
clarification in a separate document just makes it less likely that 
people will notice the clarification.

Keith


Ned Freed wrote:
On Mar 24, 2008, at 11:42 AM, Ned Freed wrote:

John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:
--On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:

The "update" of RFC2821 is making a _significant_ architectural
change to SMTP by explicitly stating AAAA records are within a
list of SMTP server discovery records.
Well, to be very precise, 2821 is ambiguous on the subject.
  Agreed.
Some people have read (and implemented) it as if the text said
"address records", implying a default MX for the AAAA case as well
as the A one.   Others have read it more narrowly and only
supporting the default for A RRs.    To the extent to which
2821bis is expected to eliminate ambiguities that were present in
2821, it had to say something on this subject.
  It might, however, be best to simply document the ambiguity. I
suspect that implementation reports would show some implementations
querying for both AAAA and A RRs, while others query only for A
RRs. I am not convinced that 2821bis _should_ try to resolve this.
I don't think we have a choice. it is obvious that this ambiguity
can lead to interoperability problems, and that means this has to be
resolved if the document is to obtain draft standard status.

Anyone who relies upon just publishing AAAA records to enable the
discovery of their receiving MTAs are unlikely to find this to be
widely interoperable.  Until such time that A records for discovery
have been deprecated, the A record method of discovery or email-
address domain validation continues to be used.  MX records have been
in use for a period long enough to safely rule out new explicitly
"implied" MX records.  The choice seems rather clear, especially in
the face of undesired traffic created by implied use of address
records.  Please don't add AAAA or any future address record to a list
of records likely to be abused by spammers.

I'm afraid this is nothing but a strawman. Nowhere did I say _how_ the
ambiguity should be resolved, only that it needs to be resolved one way
or the other. If the consensus is that better interoperability can be
had by banning bare AAAA records that's perfectly fine with me. What is not
fine is saying "maybe bare AAAA works, maybe it doesn't, good luck and
be happy". That's what I understood was being advocated and why I jumped
into this now.

you (and perhaps Mark and others) dislike the consequences and
claim "significant architectural change". If it is changed to
explicitly indicate that only A RRs can be used to imply an MX
record, then I assume that those who read 2821 the other way and
are now supporting AAAA records to generate an implied MX would
claim "significant architectural change".
  Indeed, that seems likely (though not demonstrated).
  But regardeless, we're on shaky ground if we try to force either
kind of implementation to change. May I suggest a different
starting point:
On the contrary, it is expected that options can be eliminated from
documents moving to draft, especially if in doing so an
interoperability problem is removed.

Clarity can be established and interoperability _improved_ by limiting
discovery to just A and MX records.  Perhaps a note might be included
that at some point in the future MX records may become required.

Again, I have no problem with this approach if that's what the consensus is.

  I think there's very strong consensus that the presence of an MX
RR demonstrates the intention to receive email addressed to the
domain in question. I don't think there's any consensus that the
presence of an AAAA or A RR demonstrates such an intent.
Perhaps, but the fact remains that MX-less configurations are
currently legal and in use.

While there are some that use A records, which remains largely due to
prior practices, these prior practices did _not_ include the use of
AAAA records.

Which is really irrelevant since the point I was addressing is the idea of
banning the bare A practice oing forward.

  There is, however, considerable history that the presence of an
address RR _in_combination_with_ a process listening on port 25 of
the IP address in question indicates a willingness to receive email
for a domain identical to the domain of that address RR.

To avoid ambiguity, A and not AAAA records would be an accurate
statement of prior practices.

Agreed.

OK...

  Whether or not we have any consensus that this historical
practice should be deprecated (I would vote YES!), rfc2821-bis is
not, IMHO, the right place to deprecate it.
On this we agree. We haven't gone through any sort of consensus
process on this and since there is no justification for deprecating
use of A-record-only configurations as part of a move to draft this
cannot be done at time.

Agreed, but making assurances regarding use of AAAA records for the
purpose of discovery is ill advised, to say the least.

  (If I may digress a bit, let me explain that this implied-MX rule
is a real pain to me as an ISP, in that we maintain a SMTP server
on the same IP address as a number of virtual web services; and the
implied-MX rule brings us rather significant spam traffic that I'd
_much_ rather be sending to a different IP address than the web-
server for the domain in question.)

As more SMTP domains attempt to publish policies of various sorts,
validation of the domain will also likely depend upon finding
requisite discovery records.  Adding AAAA and all future address
records to a list of SMTP discovery records fails miserably at taking
advantage of the MX record replacing the function of the generic A
record.

Another point in favor of not allowing bare AAAA records for mail routing.

  Getting back to my point, what would be wrong with changing this
language in Section 5.1 to document the ambiguity instead of trying
(probably unsuccessfully) to prescibe a single way of resolving it?
See above. This would be fine if the document were intended for
proposed but it is not. I suppose we could ask for an exception to
be made but frankly I see no grounds for granting one.

To say that AAAA records can be used for discovery would be equally
wrong from an interoperability standpoint.  The only valid solution
would be to indicate that AAAA records as a discovery mechanism may
not be supported and should not be used for this purpose.  Use MX
records instead.

Which is perfectly fine as far as I'm concerned. The question is whether
there's a consensus to resolve the ambiguity in this fashion.

                              Ned
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf