|
André Schild wrote: > @bücher.ch is allowed. > In dns this is represented as a IDN encoded name in the form of*** > > xn--bcher-kva.ch* is the ACE string, and it is this string that is > entered in the DNS. > Fine, let me rephrase; The IDN<->ACE string conversion, while ASCII-only not being a limitation in the DNS specifications itself, is restrained by protocol-by-protocol compatibility (or, lifting of restrictions to 7-bit ASCII, if you will). SMTP, as far as I'm aware, has not yet been made fully compatible, and have continued -for the past decade or so- to use the ACE representation, while applications such as MUAs do the conversion. Continuing this down the path to DNS, it is not actually DNS supporting this at this moment, but applications which are DNS clients (including the web administration / registration utilities), which do the conversion before the query (and probably the same conversion on the return). Just for fun, and to illustrate the point the IDN<->ACE conversion is actually an application exercise, try the rather new 'dig' vs. the rather old 'mail' utilities; $ dig +short bücher.ch 82.210.242.149 $ date | mail -s "test" "somethingthatdoesnotexist@bücher.ch" somethingthatdoesnotexist@bücher.ch contains invalid character '\303' Send options without primary recipient specified. Usage: mail -eiIUdEFntBDNHRV~ -T FILE -u USER -h hops -r address -s SUBJECT -a FILE -q FILE -f FILE -A ACCOUNT -b USERS -c USERS -S OPTION users The latter illustrates that, as opposed to just off-loading the conversion task to the MTA or SMTP layer(s). Similarly, a TCP dump on your SMTP(S) / MSA will show you the conversion is done before you hit any actual mail infrastructure. The same can be shown using named's named-checkzone utility. Continuing on the path forward, I suppose the really interesting part is what happens if a user@bücher.ch mailbox is created, versus a mail being delivered, versus a user logging in, versus sieve scripts. However, I somehow doubt it has anything to do with the original point of lowercasing the recipient in LMTP's handling by default. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen@xxxxxxxxxxxx t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 |
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
