Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2003-01-13 Thread Henrique de Moraes Holschuh
On Mon, 13 Jan 2003, Ted Cabeen wrote:
 So is this patch going to make it into 2.1?  I have the same problem here 
 with LMTP downcasing, and would like to have a solution that doesn't require 
 me to patch either postfix or cyrus, if possible.

Well, the patch proved itself stable, and it is in Debian.  It is up to the
CMU crew to accept it or not in 2.1, now.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2003-01-13 Thread Ted Cabeen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

In message 20021226163734.GA5176@khazad-dum, Henrique de Moraes Holschuh writ
es:
On Thu, 26 Dec 2002, John Alton Tamplin wrote:
 Henrique de Moraes Holschuh wrote:
 Here's the improved patch. It skips over the +Mailbox part of the 
 recipient,
 
 Would it make sense to make the control more generic, such as 
 downcase_account_name, and have it also apply to logins and other places 
 besides LMTP?  We have a number of users who were logging in with 

That's something that the canonical name remapping should do. I am not
touching that area right now (I need to understand that first).

So, if someone does this, it won't be me.  Besides, we HAVE to draw a line
somewhere, and tell the users to stop being wackos.

So is this patch going to make it into 2.1?  I have the same problem here 
with LMTP downcasing, and would like to have a solution that doesn't require 
me to patch either postfix or cyrus, if possible.

- -- 
Ted Cabeen   http://www.pobox.com/~secabeen[EMAIL PROTECTED] 
Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED]
I have taken all knowledge to be my province. -F. Bacon  [EMAIL PROTECTED]
Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED]


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
Comment: Exmh version 2.5 07/13/2001

iD8DBQE+IxO+oayJfLoDSdIRAltvAKC8gB4EguwlKduNX0TPc+nKLmof/QCgptWu
/8Z3gqXlmy7eW3VrXNug1ho=
=8OnW
-END PGP SIGNATURE-




Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2003-01-13 Thread Lawrence Greenfield
   Date: Mon, 13 Jan 2003 17:32:10 -0200
   From: Henrique de Moraes Holschuh [EMAIL PROTECTED]

   On Mon, 13 Jan 2003, Ted Cabeen wrote:
So is this patch going to make it into 2.1?  I have the same
problem here with LMTP downcasing, and would like to have a
solution that doesn't require me to patch either postfix or
cyrus, if possible.

   Well, the patch proved itself stable, and it is in Debian.  It is
   up to the CMU crew to accept it or not in 2.1, now.

I'm kinda unhappy about the limited scope of the patch. It makes
usernames case-insensitive during delivery, but they're case-sensitive
everywhere else. I'm not sure this is a great idea.

Maybe a global switch of case-sensitive mailbox names would make more
sense (thus LeG+detail - user.leg.Detail, and LEG could log
in). I'm not sure, though.

Larry




Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2003-01-13 Thread Henrique de Moraes Holschuh
On Mon, 13 Jan 2003, Lawrence Greenfield wrote:
 Maybe a global switch of case-sensitive mailbox names would make more
 sense (thus LeG+detail - user.leg.Detail, and LEG could log
 in). I'm not sure, though.

Nor am I. Should Cyrus do such a thing on its own? And if so, is this a
2.2-only type of feature?

What I do know is that people need some form of force-lowercase-usernames,
and doing it in Cyrus allows for mixed-case incoming folders.

OTOH, I do not like anything case-sensitive in email at all, so I'd rather
just downcase the entire thing in the MTA, and mixed-case folders become
second-class citizens in that scheme.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2003-01-13 Thread Lawrence Greenfield
   Date: Mon, 13 Jan 2003 16:31:15 -0500
   From: John Alton Tamplin [EMAIL PROTECTED]

   Lawrence Greenfield wrote:

   I'm kinda unhappy about the limited scope of the patch. It makes
   usernames case-insensitive during delivery, but they're case-sensitive
   everywhere else. I'm not sure this is a great idea.
   
   Maybe a global switch of case-sensitive mailbox names would make more
   sense (thus LeG+detail - user.leg.Detail, and LEG could log
   in). I'm not sure, though.
 
   
   I made that suggestion, and the only response at the time was negative.

I'm very fickle.
I think also a global case-sensitivity switch is considerably hard
than the patch Henrique proposed, but somehow I feel that the patch
Henrique proposed better belongs in the MTA.

I dunno. Maybe we should just commit it, solve this problem, and go on
with life.

Larry




Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2003-01-13 Thread John Alton Tamplin
Lawrence Greenfield wrote:


I'm kinda unhappy about the limited scope of the patch. It makes
usernames case-insensitive during delivery, but they're case-sensitive
everywhere else. I'm not sure this is a great idea.

Maybe a global switch of case-sensitive mailbox names would make more
sense (thus LeG+detail - user.leg.Detail, and LEG could log
in). I'm not sure, though.
 

I made that suggestion, and the only response at the time was negative.

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






Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2003-01-13 Thread John Alton Tamplin
Lawrence Greenfield wrote:


  Date: Mon, 13 Jan 2003 16:31:15 -0500
  From: John Alton Tamplin [EMAIL PROTECTED]

  Lawrence Greenfield wrote:

  I'm kinda unhappy about the limited scope of the patch. It makes
  usernames case-insensitive during delivery, but they're case-sensitive
  everywhere else. I'm not sure this is a great idea.
  
  Maybe a global switch of case-sensitive mailbox names would make more
  sense (thus LeG+detail - user.leg.Detail, and LEG could log
  in). I'm not sure, though.

  
  I made that suggestion, and the only response at the time was negative.

I'm very fickle.
I think also a global case-sensitivity switch is considerably hard
than the patch Henrique proposed, but somehow I feel that the patch
Henrique proposed better belongs in the MTA.

I dunno. Maybe we should just commit it, solve this problem, and go on
with life.
 

There seem to be 3 places that have to be dealt with:
1) login
2) message delivery
3) mailbox names

It seems like 1 is very localized and a trivial change in 
auth_canonifyid (if it isn't appropriate for Kerberos, then the switch 
could just be ignored in auth_krb*.c) .  2 is easy enough and a small 
variant of Henrique's patch should do it. 3 is much harder, since you 
potentially have to handle select Shared Folders/user/JTampli/Test to 
resolve to user/jtampli/Test and similar situations.  I think it is less 
of an issue because most clients are just going to show the user what 
LIST/etc return (and any running altnamespace won't see them except for 
other users that have granted permissions to one of their folders), so I 
would be happy with a patch that solves only 1  2 (and in fact I will 
probably implement it myself for local use if nobody is interested in 
getting into the official distribution).

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





Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2003-01-13 Thread Lawrence Greenfield
   Date: Mon, 13 Jan 2003 16:48:49 -0500
   From: John Alton Tamplin [EMAIL PROTECTED]
[...]
   There seem to be 3 places that have to be dealt with:
1) login
2) message delivery
3) mailbox names

   It seems like 1 is very localized and a trivial change in 
   auth_canonifyid (if it isn't appropriate for Kerberos, then the switch 
   could just be ignored in auth_krb*.c) .  2 is easy enough and a small 
   variant of Henrique's patch should do it. 3 is much harder, since you 
   potentially have to handle select Shared Folders/user/JTampli/Test to 
   resolve to user/jtampli/Test and similar situations.  I think it is less 
   of an issue because most clients are just going to show the user what 
   LIST/etc return (and any running altnamespace won't see them except for 
   other users that have granted permissions to one of their folders), so I 
   would be happy with a patch that solves only 1  2 (and in fact I will 
   probably implement it myself for local use if nobody is interested in 
   getting into the official distribution).

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

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

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

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?

I suspect any real solution would need to modify the mboxlist so that
mailbox keys are always downcased and inside the value is the case
preserved form which is returned by LIST. This isn't an easy upgrade
nor a trivial code change.

Larry




Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2003-01-13 Thread John Alton Tamplin
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





Re: Sendmail/Plussed Folders --WAS-- Re: [PATCH][CVS IMAPd 2.1]lmtp_downcase_rcpt implementation (2)

2003-01-04 Thread Lawrence Greenfield
--On Thursday, December 26, 2002 11:55 AM -0500 Scott Adkins 
[EMAIL PROTECTED] wrote:
[... sendmail +detail delivery ...]
Has anyone else had this problem (plussed folder emails sent to sendmail
that is configured to talk to LMTP directly, either my UNIX domain socket
or my TCP socket)?  If so, how was it resolved?


I noticed this problem some time ago and I think some of my input led to 
the FEATURE(`preserve_local_plus_detail') but I also remember it not 
working correctly with local LMTP delivery agents and the default 
configuration.

It's possible to work around this purely in the M4 macros (we've done that) 
but our sendmail configuration is fairly complicated (dealiing with our 
LDAP directory, fuzzy matching, and LMTP over TCP with LMTP AUTH) spread 
into multiple M4 files.

If you want, I can make this available to anyone who is interested. I can't 
remember the specific workaround and the M4 files aren't easily available 
to me right now.

Larry



Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2002-12-26 Thread John Alton Tamplin
Henrique de Moraes Holschuh wrote:


Here's the improved patch. It skips over the +Mailbox part of the recipient,
in the most straightforward way possible ;-)
 

Would it make sense to make the control more generic, such as 
downcase_account_name, and have it also apply to logins and other places 
besides LMTP?  We have a number of users who were logging in with 
randomly capitalized account names in UW IMAP (and it happily accepted 
them).  We have been contacting them to change it, but perhaps others 
with a similar problem might prefer to just accept it.

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





Sendmail/Plussed Folders --WAS-- Re: [PATCH][CVS IMAPd 2.1]lmtp_downcase_rcpt implementation (2)

2002-12-26 Thread Scott Adkins
--On Wednesday, December 25, 2002 10:59 AM -0200 Henrique de Moraes 
Holschuh [EMAIL PROTECTED] wrote:

Here's the improved patch. It skips over the +Mailbox part of the
recipient, in the most straightforward way possible ;-)


Sorry, didn't see this message until too late... ignore my last post on
the subject... you just fixed it :)

On another note, it seems that sendmail has issues with talking directly
to LMTP (meaning, not using the deliver program) and being able to deliver
messages to plussed folders of a user account.  At least as of sendmail
8.12.5, messages sent to plussed folders are simply deposited to the user's
INBOX.  Maybe that has been fixed by mucking around with the M4 code for
the Cyrus configuration, but I doubt it.

There is a PRESERVE_LOCAL_PLUS_DETAIL option in proto.m4 that can be used,
but as I have seen from my testing, it only works when sendmail calls the
deliver program directly (deliver -e -m $h -- $u was what we used), and
the reasoning for that is that the hostname and the username were broken
out into two seperate macros and passed individually on the deliver command
line.  Using that option with LMTP directly ends up losing the $h portion
of the macro, and only $u is sent via the LMTP protocol.  S

I ended up patching sendmail (I can post the patch, which is current as of
8.12.5, but should work for 8.12.6) that allows plussed folder details to
be passed along untouched to the LMTP server, and even implemented a flag
that would allow the username to be lowercased and leave the plussed folder
portion untouched before passing it to LMTP.

So, my question to the list is this:

Has anyone else had this problem (plussed folder emails sent to sendmail
that is configured to talk to LMTP directly, either my UNIX domain socket
or my TCP socket)?  If so, how was it resolved?

Is there a better way to do this using the M4 macros as opposed to how I
solved the problem by patching the code?

Thanks,
Scott
--
+---+
 Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/
  UNIX Systems Engineer  mailto:[EMAIL PROTECTED]
   ICQ 7626282 Work (740)593-9478 Fax (740)593-1944
+---+
PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/


msg10062/pgp0.pgp
Description: PGP signature


[PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)

2002-12-25 Thread Henrique de Moraes Holschuh
Here's the improved patch. It skips over the +Mailbox part of the recipient,
in the most straightforward way possible ;-)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

diff -ru cyrus-imapd.orig/imap/lmtpengine.c cyrus-imapd/imap/lmtpengine.c
--- cyrus-imapd.orig/imap/lmtpengine.c  2002-11-03 12:33:59.0 -0200
+++ cyrus-imapd/imap/lmtpengine.c   2002-12-25 10:57:30.0 -0200
@@ -1114,9 +1114,12 @@
 char *user;
 int r, sl;
 address_data_t *ret = (address_data_t *) xmalloc(sizeof(address_data_t));
+int forcedowncase;
 
 assert(addr != NULL  msg != NULL);
 
+forcedowncase = config_getswitch(lmtp_downcase_rcpt, 0);
+ 
 if (*addr == '') addr++;
 dest = user = addr;
 
@@ -1147,13 +1150,18 @@
}
 }
 else {
+   while (*addr != '@'  *addr != ''  *addr != '+') {
+   if (*addr == '\\') addr++;
+   if (! forcedowncase) *dest++ = *addr++;
+   else *dest++ = TOLOWER(*addr++);
+   }
while (*addr != '@'  *addr != '') {
if (*addr == '\\') addr++;
*dest++ = *addr++;
}
 }
 *dest = '\0';
-   
+
 r = verify_user(user, ignorequota ? -1 : msg-size, msg-authstate);
 if (r) {
/* we lost */
diff -ru cyrus-imapd.orig/man/imapd.conf.5 cyrus-imapd/man/imapd.conf.5
--- cyrus-imapd.orig/man/imapd.conf.5   2002-11-21 09:11:37.0 -0200
+++ cyrus-imapd/man/imapd.conf.52002-12-25 10:56:13.0 -0200
@@ -232,6 +232,8 @@
 mailbox is over quota.  By default, the failure is temporary.
 .IP \fBlmtp_allowplaintext:\fR setting of \fIallowplaintext\fR 5
 Allow the use of the SASL PLAIN mechanism for LMTP.
+.IP \fBlmtp_downcase_rcpt:\fR no 5
+If enabled, lmtpd will convert the recipient address to lowercase.
 .IP \fBpostuser:\fR none 5
 Userid used to deliver messages to shared folders.  For example, if
 set to bb, email sent to bb+shared.blah would be delivered to the