[Top] [All Lists]

Re: Minor is. It's not a pardigm change

2008-04-01 09:01:48

Hash: SHA1

Hi Arnt,

On 31 Mar 2008 at 11:32, Arnt Gulbrandsen <arnt(_at_)oryx(_dot_)com> said:
Adding IPv6 support to internet mail forces a question: If there isn't an
MX RR for a given domain, does the SMTP client fall back to looking up an A
RR, A or AAAA, or A and AAAA? We have to choose, and all of them represent
a change.

Why?  As John has pointed out, all 2821bis is saying you have to do as an 
Internet mailer is to imagine that there's an MX record of preference 0 
with the target of the recipient domain for that same recipient domain 
when there isn't one already.  That's how it's always been, and all this 
bother about whether or not it's appropriate to deny mail to recipients 
without an MX record in the IPv6 case is apparently appealing only to 
people who want it that way for purely anti-abuse motives (not, FWIW, that 
I'm saying they're inherently a bad idea - but they have no place on a 
draft-standard-to-be, for which they are entirely unmoving reasons for 
breaking this longstanding rule).  OTOH, the wording of the spec lends 
itself to this sort of non-semantic thinking, so perhaps a slight touch to 
emphasise the synthesis of the MX record more clearly rather than as a 
fallback to address records (but to be fair to John, he's made it as 
generic as he possibly can) might help.

In reality, for me at least, it's obvious what has to happen: you 
synthesise the MX record, then act on it according to your supported 
address families as you would with any other non-synthesised record - 
connect to whatever you can.  If you're feeling desperate, send the mail 
to someone else to relay it into the other network for you (this wasn't 
mentioned in the spec either, I find).

I can accept that, from an implementation point of view, there may well be 
subtle differences between uses of the synthesised MX record and the real 
thing.  For instance, you can't rely on Additional Section replies in DNS 
to include all relevant information when an MX query is made.  You have to 
make the queries for supported address types yourself.  I'm not sure you 
can rely on the Additional section anyway (DNS gurus, please advise).  
Also, there's the matter of how one actually processes the MX target; for 
standard resolver routines in system libraries that support IPv6, though, 
you'll end up with results to suit your stack(s), and most MTAs are doing 
that anyway.  For instance, gethostbyname(3) or getaddrinfo(3), which, 
with a little bit of coaxing, generally do the right thing or at least do 
it well enough.  This is clean, consistent with other protocols and 
sensible and, unless preference is given to a particular address family, I 
think giving multiple families of address for a single dual-stacked 
machine in the DNS for a single hostname is preferable to using individual 
MX records.  You can then depend on the right thing happening even when MX 
is absent, no matter with IPv4, IPv6 or both.

Someone please tell me I missed something so I can put the coffee machine 
back on and get back into my terrible habbit. :-)


- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399

Version: PGP 8
Comment: QDPGP -