Thread: [Courier-imap] Patches for virtual hosting (accesslocal, defdomain)
Brought to you by:
mrsam
Menu
▾
▴
courier-imap
|
From: Brian C. <B.C...@po...> - 2005-06-28 10:42:54
|
Here are a couple of small feature patches.
The first patch [first two attached files] adds a flag "-accesslocal" to
couriertcpd. If this is set, and the -access database is in use, then an
additional lookup is done on the local IP address and port (before looking
up the remote IP). This gives an opportunity to set environment variables
based on the IP address and/or port which the client connected to. Examples:
1.2.3.4.25 FOO=bar # connections to 1.2.3.4 port 25
1.2.3.4 FOO=baz # connections to 1.2.3.4, any other port
*.25 FOO=bap # connections to any other IP, port 25
The second patch [last two attached files] adds the ability to set a default
domain in courier-imap, based on environment variables DEFDOMAIN and
DOMAINSEP.
If only DEFDOMAIN is set, it is added if the login name does not contain the
first character of DEFDOMAIN. e.g.
DEFDOMAIN="@example.com"
Logins which don't contain '@' have '@example.com' added.
If DOMAINSEP is also set, then DEFDOMAIN is added if the login name does not
contain any character from DOMAINSEP. e.g.
DOMAINSEP="@+"
DEFDOMAIN="@example.com"
Logins which don't contain '@' or '+' have '@example.com' added.
Combining these two patches, you can do virtual hosting on a multi-homed
host, appending a different default domain depending on which IP address you
connected to:
[pop3d or imapd]
TCPDOPTS="-nodnslookup -noidentlookup -access=/etc/access.db -accesslocal"
[/etc/access]
192.168.123.123 allow,DOMAINSEP=@+,DEFDOMAIN=@example.com
192.168.123.124 allow,DOMAINSEP=@+,DEFDOMAIN=@example.net
192.168.123.125 allow,DEFDOMAIN=.example.org
192.168.123.126 allow,DOMAINSEP,DEFDOMAIN=#visp2
# In the last case, #visp2 is appended unconditionally
Remember:
( cat /etc/access; echo "." ) | makedatprog - /etc/access.tmp /etc/access.db
It might be worth adding DEFDOMAIN as an option to the default pop3/imapd
configuration files. This would benefit authuserdb and authldap users, which
currently don't have a default domain setting of their own (whereas
authpgsql and authmysql do)
Regards,
Brian.
|
|
From: Sam V. <mr...@co...> - 2005-06-29 12:43:48
|
Brian Candler writes: > The second patch [last two attached files] adds the ability to set a default > domain in courier-imap, based on environment variables DEFDOMAIN and > DOMAINSEP. The problem with your approach is that it only works for userid/passwd logins. It does not work with CRAM authentication. Something similar needs to be added to the CRAM support code. |
|
From: Brian C. <B.C...@po...> - 2005-06-29 14:37:50
|
On Wed, Jun 29, 2005 at 08:33:51AM -0400, Sam Varshavchik wrote: > >The second patch [last two attached files] adds the ability to set a > >default > >domain in courier-imap, based on environment variables DEFDOMAIN and > >DOMAINSEP. > > The problem with your approach is that it only works for userid/passwd > logins. It does not work with CRAM authentication. Something similar > needs to be added to the CRAM support code. Quite right - as I didn't need it. However if you're interested in committing this feature, I'll complete it. SASL embeds the authorisation identity within the exchange, and therefore the location of the username is specific to each mechanism. However it still seems cleanest to do this in the auth client side, otherwise I'd have to pass additional context to authdaemon (i.e. either DEFDOMAIN and DOMAINSEP, or TCPLOCALIP/TCPLOCALPORT) Hmm, it looks like changes in two places: 1. in authsasl_plain(), the SASL response is already unpicked, so I just have to append the default domain to uid with the same logic as auth_login. That's easy. 2. in authsasl_cram() the base64-encoded challenge and response are just sent directly to authdaemon. For CRAM-MD5 (RFC2195) the response is "username hexdigest"; I don't see an RFC for CRAM-SHA1 or CRAM-SHA256, but the logic in auth_get_cram() says they are the same. So I guess I need to base64-decode the response, skip to space, add the default domain if needed, and then re-base64-encode if a domain was added. Are you OK for me to bury that in authsasl_cram()? Or have you got a better suggestion on how best to achieve this? Regards, Brian. |
|
From: Sam V. <mr...@co...> - 2005-06-29 15:05:14
|
Brian Candler writes: > Are you OK for me to bury that in authsasl_cram()? Or have you got a better > suggestion on how best to achieve this? I initially thought about doing this in auth_get_cram(), which unpacks what the module receives, but the glitch there is that it overloads the buffer to store the unpacked userid and the rest of the stuff, and there's no room to add the default domain there. It might be cleaner to change auth_get_cram() to keep a statically malloced buffer, and put the userid into that buffer. There used to be a lot of this kind of code around. It was gone in the last cleanup, but for other reasons, and I don't think there's anything necessarily wrong with doing it this way. |
|
From: Brian C. <B.C...@po...> - 2005-06-30 09:03:12
|
On Wed, Jun 29, 2005 at 11:00:13AM -0400, Sam Varshavchik wrote: > I initially thought about doing this in auth_get_cram(), which unpacks what > the module receives, but the glitch there is that it overloads the buffer > to store the unpacked userid and the rest of the stuff, and there's no room > to add the default domain there. > > It might be cleaner to change auth_get_cram() to keep a statically malloced > buffer, and put the userid into that buffer. However, authsasl_frombase64() currently overwrites the data in-place, so that would require more refactoring: e.g. pass in a static buffer and buffer len, and then change everywhere that authsasl_frombase64 is called; or else make it malloc for consistency with authsasl_tobase64. In the end, it seemed to be simpler to strdup() the response before decoding it. I thought about calling auth_get_cram() to do the decoding and splitting out of the username, but that actually does more work than I needed - in particular, it also base64-decodes (and overwrites) the challenge. Regards, Brian. |
|
From: Sam V. <mr...@co...> - 2005-06-30 12:32:15
|
Brian Candler writes: > On Wed, Jun 29, 2005 at 11:00:13AM -0400, Sam Varshavchik wrote: >> I initially thought about doing this in auth_get_cram(), which unpacks what >> the module receives, but the glitch there is that it overloads the buffer >> to store the unpacked userid and the rest of the stuff, and there's no room >> to add the default domain there. >> >> It might be cleaner to change auth_get_cram() to keep a statically malloced >> buffer, and put the userid into that buffer. > > However, authsasl_frombase64() currently overwrites the data in-place, so > that would require more refactoring: e.g. pass in a static buffer and buffer > len, and then change everywhere that authsasl_frombase64 is called; or else > make it malloc for consistency with authsasl_tobase64. That's not what I meant. In auth_get_cram: static char *buffer=0; if (buffer) free(buffer); buffer=malloc(. . .); I used to do this in almost every module, in the callback setup functions. |
|
From: Brian C. <B.C...@po...> - 2005-07-01 08:51:49
|
On Thu, Jun 30, 2005 at 08:27:18AM -0400, Sam Varshavchik wrote:
> >>It might be cleaner to change auth_get_cram() to keep a statically
> >>malloced buffer, and put the userid into that buffer.
> >
> >However, authsasl_frombase64() currently overwrites the data in-place, so
> >that would require more refactoring: e.g. pass in a static buffer and
> >buffer
> >len, and then change everywhere that authsasl_frombase64 is called; or else
> >make it malloc for consistency with authsasl_tobase64.
>
> That's not what I meant.
>
> In auth_get_cram:
>
> static char *buffer=0;
>
> if (buffer)
> free(buffer);
>
> buffer=malloc(. . .);
Sure. But because authsasl_frombase64 overwrites its source, you'd still
need to copy the source into that buffer before decoding it.
Do you mean something like this (untested)?
int auth_get_cram(...)
...
static char *srcbuf=0;
if (srcbuf) free (srcbuf);
authdata = srcbuf = strdup(authdata);
if (srcbuf == 0)
{
errno = ENOMEM;
return 1;
}
... rest of auth_get_cram as before
That seems reasonable enough. The cram_callback_info structure is really
only used as an argument to the callback functions.
Cheers,
Brian.
|
|
From: Sam V. <mr...@co...> - 2005-07-01 12:03:00
|
Brian Candler writes:
> Do you mean something like this (untested)?
>
> int auth_get_cram(...)
> ...
> static char *srcbuf=0;
>
> if (srcbuf) free (srcbuf);
> authdata = srcbuf = strdup(authdata);
> if (srcbuf == 0)
> {
> errno = ENOMEM;
> return 1;
> }
>
> ... rest of auth_get_cram as before
>
> That seems reasonable enough. The cram_callback_info structure is really
> only used as an argument to the callback functions.
Yes. There used to be quite a bit of this kind of code around.
|
|
From: jonn ah <jon...@ya...> - 2005-06-30 03:18:59
|
Hi all, Is the QUOTA extension of courier-imap the same as the maildirquota? I am currently using a virtual domain and the documentation in the courier-imap says that maildirquota wont work if the maildirs are located in a different directory (it is, its located in the xmail virtual domain)....so i wanted to know if it was different and if maybe I can use the QUOTA extension for virtual domains? if not, is there a workaround to this? I wanted to make the squirrelmail check_quota plugin work but its based on courier-imap's QUOTA extension... Sorry I tried to RTFM and googling like PBXSoftware's guy but I saw no obvious solution... __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Sam V. <mr...@co...> - 2005-06-30 03:30:13
|
jonn ah writes: > Hi all, > > Is the QUOTA extension of courier-imap the same as the maildirquota? I The IMAP QUOTA extension in Courier-IMAP merely reads the working usage quota for the maildir. Whatever maildirquota is set for the maildir, the QUOTQA extension will return it. |
|
From: Brian C. <B.C...@po...> - 2005-06-29 16:44:53
Attachments:
courier-authlib-sasldefdomain
|
On Wed, Jun 29, 2005 at 08:33:51AM -0400, Sam Varshavchik wrote: > The problem with your approach is that it only works for userid/passwd > logins. It does not work with CRAM authentication. Something similar > needs to be added to the CRAM support code. Try this for size. There's a bit of duplication (auth_login, authsaslplain and authsasllogin have almost identical code) but I can live with that. Incidentally, perhaps it's worth changing in imap/pop3d.dist.in: -POP3AUTH_ORIG="LOGIN CRAM-MD5 CRAM-SHA1 CRAM-SHA256" +POP3AUTH_ORIG="PLAIN LOGIN CRAM-MD5 CRAM-SHA1 CRAM-SHA256" Otherwise, the implication is that the LOGIN sasl mechanism is supported but the PLAIN mechanism isn't (where in fact it is) Regards, Brian. |
Thanks for helping keep SourceForge clean.
X