Tuning some defaults for 2.5: lmtp_downcase_rcpt

[Jeroen van Meeuwen (Kolab Systems)]

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