[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-24 14:18:49

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.


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.

If it says "address records" (as the current text does),

  Actually, it says "address RR" (if I understand what text we're  
discussing). I believe we're discussing Section 5.1 of

where it says
" The lookup first attempts to locate an MX record associated with  
" name.  If a CNAME record is found instead, the resulting name is
" processed as if it were the initial name.  If no MX records are
" found, but an address RR (i.e., either an IPv4 A RR or an IPv6 AAAA
" RR, or their successors) is found, the address RR is treated as  
if it
" was associated with an implicit MX RR, with a preference of 0,
" pointing to that host.

(Please correct me if I misunderstand what text we're discussing.)

This is the correct section.

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.

  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.

  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.


  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  

  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.


IETF mailing list