Tuning some defaults for 2.5: lmtp_downcase_rcpt
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Fri Feb 11 16:25:56 EST 2011
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 at bücher.ch"
somethingthatdoesnotexist at 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 at 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 at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20110211/9226652a/attachment.html
More information about the Info-cyrus
mailing list