Lawrence Greenfield wrote:

Well, "message delivery" and "mailbox names" are tightly
intertwined. How should I know that "leg+detail" should be delivered
to "user.leg.Detail"?

There is no historical usage that says imap folder names within a mailbox aren't case sensitive, so I would say leg+Detail should be delivered to user.leg.Detail and leg+detail should bounce (or actually get dropped into INBOX). The issue is that users have treated mail addresses as case insensitive and other implementations have enforced that.

You also need to prevent two mailboxes from being created with the
same name (except for case).

If we are only talking about smashing the case on user names and therefore mailboxes, couldn't that be handled both for delivery and other uses in mboxname*_tointernal?

There's the i18n problem: case mapping isn't trivial across lots of
languages.

True. Since mail addresses are defined in US-ASCII, where is the mapping from RFC2047 into the actual characters done? It seems the case mapping should be done there, at the point you know the character set. If, as in most cases, it is US-ASCII or a Latin1 character set, it is easy to implement. That will get the majority of the need with little effort. For those other character sets, it isn't clear there is as much of a need since they don't have historical implementations that smashed case in the user part of the email address to deal with.

Finally, we need to deal with people toggling this option on and
off. What happens if user.leg.foo and user.leg.Foo both exist, and
then the administrator turns on case-insensitivity?

Since what I am proposing only affects user names, that example wouldn't be a problem. If user.foo and user.Foo exist and the option is turned on, then user.Foo won't be able to receive any mail. I don't think Cyrus should protect sysadmins from that any more than it should protect against them deleting a mailbox they shouldn't.

--
John A. Tamplin Unix System Administrator
Emory University, School of Public Health +1 404/727-9931



Reply via email to