Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt

2011-02-14 Thread Andrew Morgan
On Fri, 11 Feb 2011, Jeroen van Meeuwen (Kolab Systems) wrote:

 Hi there,

 (This is a re-posted message from our development mailing list.)

 In our IRC channel, it was suggested to look at RFC 2821, section 2.4, quoted
 as saying:

 However, exploiting the case sensitivity of mailbox local-parts impedes
 interoperability and is discouraged.

 The problem statement is as follows: The recipient is u...@domain.de, and
 while the mailbox name is u...@domain.de, or even user, the mail bounced.

 Not completely aware of the full implications and/or codebase, I wanted to put
 the topic on switching the default to be relaxed in the case of case
 sensitivity out there for discussion.

 Long story short; the proposal is to ship with a default lmtp_downcase_rcpt of
 1.

We use lmtp_downcase_rcpt=1 without any problems here.  However, our email 
addresses only contain US-ASCII characters.

Andy

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/


Tuning some defaults for 2.5: lmtp_downcase_rcpt

2011-02-11 Thread Jeroen van Meeuwen (Kolab Systems)
Hi there,

(This is a re-posted message from our development mailing list.)

In our IRC channel, it was suggested to look at RFC 2821, section 2.4, quoted 
as saying:

 However, exploiting the case sensitivity of mailbox local-parts impedes 
interoperability and is discouraged.

The problem statement is as follows: The recipient is u...@domain.de, and 
while the mailbox name is u...@domain.de, or even user, the mail bounced.

Not completely aware of the full implications and/or codebase, I wanted to put 
the topic on switching the default to be relaxed in the case of case 
sensitivity out there for discussion.

Long story short; the proposal is to ship with a default lmtp_downcase_rcpt of 
1.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeu...@kolabsys.com
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/

Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt

2011-02-11 Thread André Schild

Hello,

Am 11.02.2011 14:11, schrieb Jeroen van Meeuwen (Kolab Systems):


Hi there,

(This is a re-posted message from our development mailing list.)

In our IRC channel, it was suggested to look at RFC 2821, section 2.4, 
quoted as saying:


However, exploiting the case sensitivity of mailbox local-parts 
impedes interoperability and is discouraged.


The problem statement is as follows: The recipient is u...@domain.de, 
and while the mailbox name is u...@domain.de, or even user, the 
mail bounced.


Not completely aware of the full implications and/or codebase, I 
wanted to put the topic on switching the default to be relaxed in the 
case of case sensitivity out there for discussion.


Long story short; the proposal is to ship with a default 
lmtp_downcase_rcpt of 1.




Sound OK for me.

When chaning upper/lowercases we always have to consider character sets.
For the user part it's no problem because here only basic characters are 
allowed,

but what about a mailbox like:  user@BÜCHER.CH   ?

How is this represented in the store ?
Via the same IDN mapping as for the dns servers ?
If yes, then we don't have a problem,
but otherwise this will potentially cause problems in the future.

André


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt

2011-02-11 Thread Jeroen van Meeuwen (Kolab Systems)
André Schild wrote:
 Hello,
 
 Am 11.02.2011 14:11, schrieb Jeroen van Meeuwen (Kolab Systems):
  Long story short; the proposal is to ship with a default
  lmtp_downcase_rcpt of 1.
 
 Sound OK for me.
 
 When chaning upper/lowercases we always have to consider character sets.
 For the user part it's no problem because here only basic characters are
 allowed,
 but what about a mailbox like:  user@BÜCHER.CH   ?
 

I don't think these characters are allowed in DNS / KRB, so hopefully that 
addresses that concern.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeu...@kolabsys.com
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/

Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt

2011-02-11 Thread André Schild

Am 11.02.2011 15:06, schrieb Jeroen van Meeuwen (Kolab Systems):


André Schild wrote:

 Hello,



 Am 11.02.2011 14:11, schrieb Jeroen van Meeuwen (Kolab Systems):

  Long story short; the proposal is to ship with a default

  lmtp_downcase_rcpt of 1.



 Sound OK for me.



 When chaning upper/lowercases we always have to consider character sets.

 For the user part it's no problem because here only basic characters are

 allowed,

 but what about a mailbox like: user@BÜCHER.CH ?



I don't think these characters are allowed in DNS / KRB, so hopefully 
that addresses that concern.




@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.


For technical reasons, the character string that has been processed by 
the algorithm is several


https://www.nic.ch/reg/wcmPage.action;jsessionid=256F10E27B3713EEAF8E2FBD89827125?lid=enplain=res=/reg/guest/faqs/idn.jsp

André

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt

2011-02-11 Thread 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@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: vanmeeu...@kolabsys.com
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/