All,
In the name of keeping thread subjects accurate and to allow me to restate my issue, this message...
I have imapd and imapd-ssl both running, ports 143 and 993, as expected, and my /etc/services correctly identifies these two:
imap 143/tcp imap2 # Interim Mail Access Proto v2
imap 143/udp imap2
imaps 993/tcp # IMAP over SSL imaps 993/udp # IMAP over SSL
However, courier never sees "imaps" (or is courier dumping the "s"?). The same problem exists for pop3 vs pop3s. I have verified this by using $(service) in my MYSQL_SELECT_CLAUSE, but the problem is not limited to just that query of course.
I am not sure where to look to get an idea of why everything is "dumbed down" to just "imap".
I'd appreciate any pointers!
Thanks,
Paul
p dont think wrote:
One problem solved, one more problem identified. Sigh...
The problem here was that comment lines with a backslash on the end were being wrapped. I had such a comment line right above my MYSQL_SELECT_CLAUSE, so my real MYSQL_SELECT_CLAUSE was getting folded into a comment line. It looked similar to this:
#MYSQL_SELECT_CLAUSE SELECT id, crypt_pwd, clear_pwd, \ MYSQL_SELECT_CLAUSE SELECT id, crypt_pwd, '', \
I am not certain, but shouldn't such backslashes be ignored in comment lines? I'm sure I wouldn't be the only person surprised by this. Attached is a patch that fixes that.
However, now I see in my logs that $(service) is not giving what it promised. I am using $(service) with the hopes that it can tell me the difference between users hitting imapd-ssl and those using imapd. However, *both* are showing "imap" in my query logs. Pop3 has the same problem, pop3d-ssl connections have $(service) as merely pop3.
Can anyone please comment on why that would happen? Grumble grumble....
Cheers!
p dont think wrote:
bump.
is there any reason why MYSQL_SELECT_CLAUSE would be ignored?
If anyone is watching and can be of help, I just inserted a print of the MYSQL_SELECT_CLAUSE right after its value is read in authlib/authmysqllib.c on line 650, and its value is null. Er, what? I double checked that there isn't a typo in the name MYSQL_SELECT_CLAUSE and that it is not commented out, but it doesn't appear to be anything easy like that.
Before I dig further, can anyone comment why read_env() wouldn't read it or wouldn't find it?
select_clause=read_env("MYSQL_SELECT_CLAUSE");
Thanks,
Paul
Lindsay Haisley <fmouse-courier <at> fmp.com> writes:
This was a config error on my part. I corresponded with Sam off-list.
Hrm, that's not quite what I wanted to hear. ;)
Here's my post to him:
From fmouse <at> fmp.com Wed Sep 15 18:03:04 2004 Date: Wed, 15 Sep 2004 18:03:04 -0500 From: Lindsay Haisley <fmouse <at> fmp.com> To: Sam Varshavchik <mrsam <at> courier-mta.com> Subject: Re: Any progress with MYSQL_SELECT_CLAUSE ?? Organization: FMP Computer Services
It was my error. The box I'm working on doesn't have a domain name yet (I'm
after the owners to give it one!) and I didn't have DEFAULT_DOMAIN set in
authmysqlrc. This was causing MYSQL_SELECT_CLAUSE to fail because defdomain
wasn't defined in parse_select_clause(). If I didn't use
Hrm. I don't have that defined, either, but never have, and never have had any
problem as such. But for fun, I defined it and restarted the auth daemon. Watchin the SQL logs, this doesn't seem to change anything: I see zero errors,
but the query being fed to MySQL is the one built out of the other fields in
authmysqlrc.
The comments suggest that as long as you define MYSQL_SELECT_CLAUSE that the
other query-related fields will be ignored. Is this inaccurate? Do I need to
comment or otherwise remove any of them? If so, which ones?
Just to make sure I'm not going insane, I changed the value of some of those
other fields just to make sure I'm using the right config file, and the change
was immediately reflected in my MySQL logs.
So there is something that is not allowing the use of MYSQL_SELECT_CLAUSE, but I
don't see what it would be. Can anyone shed some light?
If I have to poke in the code, I will (rather not...) -- can someone point me to
the right place (files/fxns)?
Thanks,
Paul
MYSQL_SELECT_CLAUSE I could successfully run courier with authmysql using
the IP address for the box.
Sorry for the fire drill!!
Thus spake Sam Varshavchik on Wed, Sep 15, 2004 at 05:33:40PM CDT
Lindsay Haisley writes:
I'm back to working on the customer system I mentioned previously using courier 0.46. Has any progress been made in the development version on the MYSQL_SELECT_CLAUSE problem I inquired about a couple of weeks ago? I'm going to work on debugging it, but don't want to reinvent the wheel if it's already been solved.
Sorry, haven't get around to it just yet. I'll let you know as soon as I
have something. Although, someone on the mailing list did confirm that
MYSQL_SELECT_CLAUSE works for them, so???
Thus spake p dont think on Fri, Dec 17, 2004 at 03:31:59PM CST
All,
Wondering if this has been looked at lately. I get slightly different
side effects, wherein the select clause seems to simply be ignored, but
nevertheless, it might be the same problem. I suppose I can take a look
at the code, not that I have the time, but if someone wants to point me
to the right place in the code maybe I'll make the time...
Thanks,
Paul
Original Message: =========================
From: Sam Varshavchik <mrsam <at> courier-mta.com> Subject: Re: MYSQL_SELECT_CLAUSE again Newsgroups: gmane.mail.imap.courier.general Date: Wed, 01 Sep 2004 18:48:04 -0400
Lindsay Haisley writes:
No help there, either. I added it to authdaemonrc, and also as an
enviroment var in the authdaemond startup line in /etc/init.d/courier,
but I don't get anything informative in syslog, only the usual ....
Sep 1 11:17:58 mail01 courieresmtpd: error,relay=::ffff:127.0.0.1,ident=root,from=<fmouse <at> bbadmin.com>,to=<foo <at> bbadmin.com>: 450 Service temporarily unavailable.
I suppose I'm going to have to hack some debugging code into authmysqllib.c in and around parse_select_clause() and calls to it. I don't really have time to mess with it right now, but maybe next week....
Presuming that the environment variable is properly set, the lack of any
debugging output does narrow the culprit somewhat.
My time is also a bit tight, but I also intend to investigate it. Let's
see who finds this bug first.
------------------------------------------------------------------------
--- authlib/authmysqllib.c.orig 2004-12-22 16:03:21.000000000 -0800
+++ authlib/authmysqllib.c 2004-12-22 16:13:48.000000000 -0800
@@ -44,7 +44,8 @@
static size_t mysqlauth_size=0;
size_t i;
char *p=0;
-int l=strlen(env);
+int l=strlen(env),
+ is_comment=0;
if (!mysqlauth)
{
@@ -67,10 +68,18 @@
}
mysqlauth[mysqlauth_size=buf.st_size]=0;
+ if (mysqlauth[0] == '#')
+ {
+ is_comment = 1;
+ }
+ else
+ {
+ is_comment = 0;
+ }
for (i=0; i<mysqlauth_size; i++)
if (mysqlauth[i] == '\n')
{ /* [EMAIL PROTECTED] */
- if (!i || mysqlauth[i-1] != '\\')
+ if (!i || is_comment || mysqlauth[i-1] != '\\')
{
mysqlauth[i]='\0';
}
@@ -78,6 +87,15 @@
{
mysqlauth[i]=mysqlauth[i-1]= ' ';
}
+
+ if (mysqlauth[i+1] == '#')
+ {
+ is_comment = 1;
+ }
+ else
+ {
+ is_comment = 0;
+ }
}
fclose(f);
}
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
