Re: [Dbmail-dev] CVS Patch for dynmaic table prefixes...
Paul,
On the default where if the prefix is not specified it needs to be
changed to look like this. Didn't feel like doing a diff. This is because
we need pople to be able to specify a prefix of your fix doesn't allow
for this I have changed my config.c function to look like such:
void GetDBParams(db_param_t * db_params)
{
field_t port_string;
field_t sock_string;
if (GetConfigValue(host, DBMAIL, db_params-host) 0)
trace(TRACE_FATAL, %s,%s: error getting config!,
__FILE__, __func__);
if (GetConfigValue(db, DBMAIL, db_params-db) 0)
trace(TRACE_FATAL, %s,%s: error getting config!,
__FILE__, __func__);
if (GetConfigValue(user, DBMAIL, db_params-user) 0)
trace(TRACE_FATAL, %s,%s: error getting config!,
__FILE__, __func__);
if (GetConfigValue(pass, DBMAIL, db_params-pass) 0)
trace(TRACE_FATAL, %s,%s: error getting config!,
__FILE__, __func__);
if (GetConfigValue(sqlport, DBMAIL, port_string) 0)
trace(TRACE_FATAL, %s,%s: error getting config!,
__FILE__, __func__);
if (GetConfigValue(sqlsocket, DBMAIL, sock_string) 0)
trace(TRACE_FATAL, %s,%s: error getting config!,
__FILE__, __func__);
if (GetConfigValue(table_prefix, DBMAIL, db_params-pfx) 0){
trace(TRACE_FATAL, %s,%s: error getting config!,
__FILE__, __func__);
if (strlen(db_params-pfx) == 0)
strncpy(db_params-pfx, DEFAULT_DBPFX, FIELDSIZE);
}
/* check if port_string holds a value */
if (strlen(port_string) != 0) {
db_params-port =
(unsigned int) strtoul(port_string, NULL, 10);
if (errno == EINVAL || errno == ERANGE)
trace(TRACE_FATAL,
%s,%s: wrong value for sqlport in
config file, __FILE__, __func__);
} else
db_params-port = 0;
/* same for sock_string */
if (strlen(sock_string) != 0)
strncpy(db_params-sock, sock_string, FIELDSIZE);
else
db_params-sock[0] = '\0';
}
notice the DEFAULT_DBPFX is withing the case check for the item in the
config file.
Thanks,
leif
Re: [Dbmail-dev] Spotty timezone support
On Wed, 15 Sep 2004 17:14:34 -, Aaron Stone [EMAIL PROTECTED] wrote: Wolfram A. Kraushaar [EMAIL PROTECTED] said: Shouldn't the Timzone be taken from the environment var TZ as defined by POSIX.1? The TZ variable is a disaster zone of inconsist and bizarre formatting rules. There might be some proven, reliable L/GPL code already out there, but writing our own would be a really unpleasant task. What I did was take the timezone information from tm_gmtoffset (BSD GNU extension of the tm struct). This seemed to work very well, until someone in Australia mentioned that he got the wrong timezone, +1100 instead of +1000. +1100 is his daylight savings time. It's currently is winter in Australia, so no DST there now! There must be something wrong with my code... Anyone who knows something about this, please take a look at the date_sql2imap() function in imaputil.c Ilja
[Dbmail-dev] [DBMail 0000079]: INTERNALDATE reponses do not conform to RFC
A BUGNOTE has been added to this bug.
==
http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=079
==
Reported By:scocking
Assigned To:ilja
==
Project:DBMail
Bug ID: 79
Category: IMAP daemon
Reproducibility:always
Severity: major
Priority: high
Status: feedback
==
Date Submitted: 30-Aug-04 12:39 CEST
Last Modified: 16-Sep-04 11:53 CEST
==
Summary:INTERNALDATE reponses do not conform to RFC
Description:
The SnapperMail IMAP client is extremely strict in its IMAP protocol
adherence, and requires that INTERNALDATE responses are formatted in
dd-mmm- hh:mm:ss + format as per the RFC. DBmail always
responds without the + timezone.
==
--
ilja - 03-Sep-04 14:00 CEST
--
fixed by doing the following:
instead of using array magic etc, the two date functions date_imap2sql()
and date_sql2imap() now use strptime() and strftime() to parse and format
the date time. date_sql2imap() outputs the timezone information with the
date and time.
fix has been applied to HEAD, dbmail_2_0_branch. A patch has been prepared
for dbmail_1_2_branch.
--
scocking - 08-Sep-04 10:15 CEST
--
The supplied fix sends a timezone in its INTERNALDATE response, but the
timezone is incorrect. The timezone presented is daylight time, when
local time is not.
An example seen by an IMAP client follows:
0295 * 53 FETCH (UID 1290296 FLAGS (\Seen \Answered \Recent) ENVELOPE
(Wed, 8 Sep 2004 17:29:45 +1000 Email subject (({12} NIL email
domain.com)) (({12} NIL email domain.com)) (({12} NIL email
domain.com)) (({15} NIL simon mailguard.com.au)) NIL NIL NIL
[EMAIL PROTECTED])
BODY[HEADER.FIELDS (REFERENCES)] {2} INTERNALDATE 08-Sep-2004 17:33:11
+1100 snip
The correct UTC offset for this location is +1000. +1100 is our daylight
offset.
I have triple-checked the server's timezone settings, and they're correct.
All other software on this machine reports correct time. E.g.
# date -R
Wed, 8 Sep 2004 18:14:27 +1000
(I had a quick crack at fixing this myself. My system documentation
doesn't show a tm_gmtoff member to struct tm, and I've never seen that
myself. Could this be the culprit?)
Simon.
--
ilja - 08-Sep-04 10:36 CEST
--
Hmm.. I just checked. It works here (I get +0100, which is correct here).
So, you don't have tm_gmtoff in your tm struct. What system are you
running? tm_gmtoff is a BSD GNU extension.
--
ilja - 08-Sep-04 13:37 CEST
--
I'm getting more and more confused on how timezone stuff should work...
--
ilja - 08-Sep-04 14:17 CEST
--
hmm, of course it works correct here. We _are_ on daylights savings time.
Hmm, I've just found a bug here. I managed to screw up something. I
correctly get +0200 now. The bug's not in the patch I sent earlier.
Anyway. I don't know what we should do here. I've posted a question on
Usenet in comp.lang.c, perhaps we'll get a useful answer there.
--
ilja - 15-Sep-04 16:32 CEST
--
I haven't received any useful information from comp.lang.c...
I'm currently at a loss how to solve this..
--
aaron - 15-Sep-04 17:23 CEST
--
What if we just ask the database for a formatted time response?
--
ilja - 15-Sep-04 17:28 CEST
--
Of course!
We only need to find the places where we ask the database for an
INTERNALDATE, but I'm thinking we only ask for it in this IMAP code..
It might just work. I only hope
Re: [Dbmail-dev] Spotty timezone support
On Thu, 16 Sep 2004 11:51:31 +0200, Wolfram A. Kraushaar [EMAIL PROTECTED] wrote: Not sure if adding that helps: tm_sqldate.tm_isdst = tm_localtime.tm_isdst; Hmm, you might be right about that one. This might just be it. I'll have a go at it. thanks, Ilja
[Dbmail-dev] [DBMail 0000086]: quota exceeded causes forwards to fail
The following bug has been ASSIGNED.
==
http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=086
==
Reported By:jnorell
Assigned To:ilja
==
Project:DBMail
Bug ID: 86
Category: PIPE delivery (dbmail-smtp)
Reproducibility:always
Severity: major
Priority: normal
Status: assigned
==
Date Submitted: 09-Sep-04 21:26 CEST
Last Modified: 16-Sep-04 12:00 CEST
==
Summary:quota exceeded causes forwards to fail
Description:
When an alias lookup resolves to multiple deliver_to's with at least one
local INBOX delivery and one or more external forwards, if the local
mailbox is over quota the external forwards are sent an empty message
rather than the real email.
==
--
aaron - 09-Sep-04 21:44 CEST
--
I think you're exactly right about moving the quota checks to follow the
forwards. Try that out and see if that patches it right up. The new
delivery chain in 2.0 should not be affected, but it would be prudent to
double check it against related bugs... like what happens if the *delivery
user* has a quota applied, for whatever odd reason, or with combinations
of within quota, above quota and non-quota accounts and forwards.
--
jnorell - 11-Sep-04 01:08 CEST
--
After surmounting the delivery-chain learning curve, a fix is quite simple,
and that's just it (move forwards to happen before quota checks). Patch
is attached, tested only in pgsql, but is working fine on our production
machines so far.
--
ilja - 14-Sep-04 14:14 CEST
--
I can't apply the patch. It bails out when trying to patch
pgsql/dbpgsql.c.
Also, the patch looks a bit big. Does it change more than only the
forwarding code?
Jesse, can you please make a patch that applies cleanly to dbmail 1.2 CVS
(not 1.2.10)
--
jnorell - 14-Sep-04 16:37 CEST
--
You sure you didn't miss a -p1 or something? It applies clean for me:
mail2:/usr/src/dbmail# ./grab_latest_cvs
Press [Enter] at 'CVS password:' prompt
Logging in to :pserver:[EMAIL PROTECTED]:2401/cvsroot-dbmail
CVS password:
Got latest cvs code - in directory dbmail_1_2-20040914
mail2:/usr/src/dbmail# cd dbmail_1_2-20040914
mail2:/usr/src/dbmail/dbmail_1_2-20040914# patch -p1
../dbmail_1_2-20040910_nullforward.patch
patching file forward.c
patching file mysql/dbmysql.c
patching file pgsql/CVS/Entries
patching file pgsql/dbpgsql.c
patching file pipe.c
The only things that aren't strictly towards this fix are a bit of
cleanup for a couple things that aren't needed (eg. some extra
if (..) { .. }'s for conditions that will never be true because you're
already in an else { .. } for that same condition) and added a trace
to dbpgsql.c to complain if we were requested to forward a db message
and that message has no messageblks, removed a math bug in the % display
here:
trace (TRACE_DEBUG,pipe_forward(): Sending block
-size=%d total=%d (%d\%), usedmem, totalmem,
-(((usedmem/totalmem)*100)));
+size=%d total=%d, usedmem, totalmem);
And I removed this trace(), which I've always wish I never left in a
patch last year :)
trace (TRACE_DEBUG,db_send_message_lines(): Using %d size
buffer,WRITE_BUFFER_SIZE);
--
ilja - 14-Sep-04 16:45 CEST
--
OK, I must be doing something wrong then..
but why's this?:
patching file pgsql/CVS/Entries
Ilja
--
jnorell - 14-Sep-04 17:05 CEST
--
I'd guess this is from a tag in dbpgsql.c, maybe? Perhaps I have more in
my local dir than I should (should not have CVS directory?) or maybe it's
harmless .. the change (which I didn't make manually) is:
---
[Dbmail-dev] [DBMail 0000086]: quota exceeded causes forwards to fail
The following bug has been RESOLVED.
==
http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=086
==
Reported By:jnorell
Assigned To:ilja
==
Project:DBMail
Bug ID: 86
Category: PIPE delivery (dbmail-smtp)
Reproducibility:always
Severity: major
Priority: normal
Status: resolved
Resolution: fixed
==
Date Submitted: 09-Sep-04 21:26 CEST
Last Modified: 16-Sep-04 12:01 CEST
==
Summary:quota exceeded causes forwards to fail
Description:
When an alias lookup resolves to multiple deliver_to's with at least one
local INBOX delivery and one or more external forwards, if the local
mailbox is over quota the external forwards are sent an empty message
rather than the real email.
==
--
aaron - 09-Sep-04 21:44 CEST
--
I think you're exactly right about moving the quota checks to follow the
forwards. Try that out and see if that patches it right up. The new
delivery chain in 2.0 should not be affected, but it would be prudent to
double check it against related bugs... like what happens if the *delivery
user* has a quota applied, for whatever odd reason, or with combinations
of within quota, above quota and non-quota accounts and forwards.
--
jnorell - 11-Sep-04 01:08 CEST
--
After surmounting the delivery-chain learning curve, a fix is quite simple,
and that's just it (move forwards to happen before quota checks). Patch
is attached, tested only in pgsql, but is working fine on our production
machines so far.
--
ilja - 14-Sep-04 14:14 CEST
--
I can't apply the patch. It bails out when trying to patch
pgsql/dbpgsql.c.
Also, the patch looks a bit big. Does it change more than only the
forwarding code?
Jesse, can you please make a patch that applies cleanly to dbmail 1.2 CVS
(not 1.2.10)
--
jnorell - 14-Sep-04 16:37 CEST
--
You sure you didn't miss a -p1 or something? It applies clean for me:
mail2:/usr/src/dbmail# ./grab_latest_cvs
Press [Enter] at 'CVS password:' prompt
Logging in to :pserver:[EMAIL PROTECTED]:2401/cvsroot-dbmail
CVS password:
Got latest cvs code - in directory dbmail_1_2-20040914
mail2:/usr/src/dbmail# cd dbmail_1_2-20040914
mail2:/usr/src/dbmail/dbmail_1_2-20040914# patch -p1
../dbmail_1_2-20040910_nullforward.patch
patching file forward.c
patching file mysql/dbmysql.c
patching file pgsql/CVS/Entries
patching file pgsql/dbpgsql.c
patching file pipe.c
The only things that aren't strictly towards this fix are a bit of
cleanup for a couple things that aren't needed (eg. some extra
if (..) { .. }'s for conditions that will never be true because you're
already in an else { .. } for that same condition) and added a trace
to dbpgsql.c to complain if we were requested to forward a db message
and that message has no messageblks, removed a math bug in the % display
here:
trace (TRACE_DEBUG,pipe_forward(): Sending block
-size=%d total=%d (%d\%), usedmem, totalmem,
-(((usedmem/totalmem)*100)));
+size=%d total=%d, usedmem, totalmem);
And I removed this trace(), which I've always wish I never left in a
patch last year :)
trace (TRACE_DEBUG,db_send_message_lines(): Using %d size
buffer,WRITE_BUFFER_SIZE);
--
ilja - 14-Sep-04 16:45 CEST
--
OK, I must be doing something wrong then..
but why's this?:
patching file pgsql/CVS/Entries
Ilja
--
jnorell - 14-Sep-04 17:05 CEST
--
I'd guess this is from a tag in dbpgsql.c, maybe? Perhaps I have more in
my local dir than I should (should not have CVS directory?) or maybe it's
harmless .. the change (which I didn't make manually)
[Dbmail-dev] [DBMail 0000090]: -n switch is non-functional for dbmail-util
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=090 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 90 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: major Priority: normal Status: confirmed == Date Submitted: 15-Sep-04 12:45 CEST Last Modified: 16-Sep-04 16:10 CEST == Summary:-n switch is non-functional for dbmail-util Description: Despite using -n actions are still performed. == -- ilja - 15-Sep-04 15:37 CEST -- The same seems to be the fact for dbmail-users. Aaron, is this intented, is it a slip? Should we perhaps just remove the documentation for the '-n' option? (from man-pages and on-line help) -- aaron - 15-Sep-04 17:04 CEST -- Gaa, there I go again. I remember looking at the queries involved in database cleanup and not figuring out how I was going to implement proper output for, say, 'dbmail-util -nv -cturpd' where it should tell you all about what it wants to fix but not actually fix anything... and then moving onto other parts of the project and not getting back to those queries :-\ I suppose we should pull -n for now, unless there's some trivially simple logic to prevent actions from being taken that I didn't see the first time around. I would suggest using the same type of error message as is currently being used for '-i' interactive option (which may never be implemented, but I thought it would be appropriate to reserve the option letter in all of the binaries). -- ilja - 15-Sep-04 17:16 CEST -- So, what would be the best way to pull this out? * remove from accepted switches in getopt() call. * remove from help output * remove from man page is that all? -- aaron - 15-Sep-04 17:29 CEST -- I'd rather leave it in getopt but add a warning like -i has. We could remove it from help and man pages... I'd like to implement the functionality in a point release, so we'd just remove the warning and let it begin working. -- ilja - 16-Sep-04 16:10 CEST -- I've done the following for dbmail-users and dbmail-util in dbmail_2_0_branch: -n -y options only display a message that they are not supported in this version. -h does not display those options. They've also been commented out in the manpages. Bug History Date Modified Username FieldChange == 15-Sep-04 12:45paul New Bug 15-Sep-04 15:37ilja Bugnote Added: 247 15-Sep-04 15:39ilja Status new = confirmed 15-Sep-04 17:04aaron Bugnote Added: 250 15-Sep-04 17:16ilja Bugnote Added: 251 15-Sep-04 17:29aaron Bugnote Added: 254 16-Sep-04 16:10ilja Bugnote Added: 268 ==
[Dbmail-dev] [DBMail 0000090]: -n switch is non-functional for dbmail-util
The following bug has been ASSIGNED. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=090 == Reported By:paul Assigned To:ilja == Project:DBMail Bug ID: 90 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: major Priority: normal Status: assigned == Date Submitted: 15-Sep-04 12:45 CEST Last Modified: 16-Sep-04 16:46 CEST == Summary:-n switch is non-functional for dbmail-util Description: Despite using -n actions are still performed. == -- ilja - 15-Sep-04 15:37 CEST -- The same seems to be the fact for dbmail-users. Aaron, is this intented, is it a slip? Should we perhaps just remove the documentation for the '-n' option? (from man-pages and on-line help) -- aaron - 15-Sep-04 17:04 CEST -- Gaa, there I go again. I remember looking at the queries involved in database cleanup and not figuring out how I was going to implement proper output for, say, 'dbmail-util -nv -cturpd' where it should tell you all about what it wants to fix but not actually fix anything... and then moving onto other parts of the project and not getting back to those queries :-\ I suppose we should pull -n for now, unless there's some trivially simple logic to prevent actions from being taken that I didn't see the first time around. I would suggest using the same type of error message as is currently being used for '-i' interactive option (which may never be implemented, but I thought it would be appropriate to reserve the option letter in all of the binaries). -- ilja - 15-Sep-04 17:16 CEST -- So, what would be the best way to pull this out? * remove from accepted switches in getopt() call. * remove from help output * remove from man page is that all? -- aaron - 15-Sep-04 17:29 CEST -- I'd rather leave it in getopt but add a warning like -i has. We could remove it from help and man pages... I'd like to implement the functionality in a point release, so we'd just remove the warning and let it begin working. -- ilja - 16-Sep-04 16:10 CEST -- I've done the following for dbmail-users and dbmail-util in dbmail_2_0_branch: -n -y options only display a message that they are not supported in this version. -h does not display those options. They've also been commented out in the manpages. Bug History Date Modified Username FieldChange == 15-Sep-04 12:45paul New Bug 15-Sep-04 15:37ilja Bugnote Added: 247 15-Sep-04 15:39ilja Status new = confirmed 15-Sep-04 17:04aaron Bugnote Added: 250 15-Sep-04 17:16ilja Bugnote Added: 251 15-Sep-04 17:29aaron Bugnote Added: 254 16-Sep-04 16:10ilja Bugnote Added: 268 16-Sep-04 16:46ilja Assigned To = ilja 16-Sep-04 16:46ilja Status confirmed = assigned ==
[Dbmail-dev] [DBMail 0000090]: -n switch is non-functional for dbmail-util
The following bug has been RESOLVED. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=090 == Reported By:paul Assigned To:ilja == Project:DBMail Bug ID: 90 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: major Priority: normal Status: resolved Resolution: fixed == Date Submitted: 15-Sep-04 12:45 CEST Last Modified: 16-Sep-04 16:48 CEST == Summary:-n switch is non-functional for dbmail-util Description: Despite using -n actions are still performed. == -- ilja - 15-Sep-04 15:37 CEST -- The same seems to be the fact for dbmail-users. Aaron, is this intented, is it a slip? Should we perhaps just remove the documentation for the '-n' option? (from man-pages and on-line help) -- aaron - 15-Sep-04 17:04 CEST -- Gaa, there I go again. I remember looking at the queries involved in database cleanup and not figuring out how I was going to implement proper output for, say, 'dbmail-util -nv -cturpd' where it should tell you all about what it wants to fix but not actually fix anything... and then moving onto other parts of the project and not getting back to those queries :-\ I suppose we should pull -n for now, unless there's some trivially simple logic to prevent actions from being taken that I didn't see the first time around. I would suggest using the same type of error message as is currently being used for '-i' interactive option (which may never be implemented, but I thought it would be appropriate to reserve the option letter in all of the binaries). -- ilja - 15-Sep-04 17:16 CEST -- So, what would be the best way to pull this out? * remove from accepted switches in getopt() call. * remove from help output * remove from man page is that all? -- aaron - 15-Sep-04 17:29 CEST -- I'd rather leave it in getopt but add a warning like -i has. We could remove it from help and man pages... I'd like to implement the functionality in a point release, so we'd just remove the warning and let it begin working. -- ilja - 16-Sep-04 16:10 CEST -- I've done the following for dbmail-users and dbmail-util in dbmail_2_0_branch: -n -y options only display a message that they are not supported in this version. -h does not display those options. They've also been commented out in the manpages. -- ilja - 16-Sep-04 16:48 CEST -- * -n and -y switches have been commented out in manpages. * -h does not show these switches anymore * when choosen, a message is displayed that those options do no work for this release and program is stopped. The points above go for dbmail-util and dbmail-users, in both HEAD and dbmail_2_0_branch Bug History Date Modified Username FieldChange == 15-Sep-04 12:45paul New Bug 15-Sep-04 15:37ilja Bugnote Added: 247 15-Sep-04 15:39ilja Status new = confirmed 15-Sep-04 17:04aaron Bugnote Added: 250 15-Sep-04 17:16ilja Bugnote Added: 251 15-Sep-04 17:29aaron Bugnote Added: 254 16-Sep-04 16:10ilja Bugnote Added: 268 16-Sep-04 16:46ilja Assigned To = ilja 16-Sep-04 16:46ilja Status confirmed = assigned 16-Sep-04 16:48ilja Bugnote Added: 269 16-Sep-04
[Dbmail-dev] [DBMail 0000092]: dbmail-users shouldn't touch encryption type when not ask to
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=092 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 92 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 16-Sep-04 19:20 CEST Last Modified: 16-Sep-04 19:20 CEST == Summary:dbmail-users shouldn't touch encryption type when not ask to Description: dbmail-users changes the encryption type even when no such change is requested. == Bug History Date Modified Username FieldChange == 16-Sep-04 19:20paul New Bug ==
[Dbmail-dev] IMAP LIST Fails in CVS2.0 / CVS2.1 but OK in dbmail-2.0rc8 (?)
Has anyone noticed that IMAP LIST fails in current CVS2.0 / CVS2.1 but functions correctly in dbmail-2.0rc8? I just installed/removed each of the above while switching to the corresponding conf files. Before I explore further... has anyone else checked this? Mike
Re: [Dbmail-dev] IMAP LIST Fails in CVS2.0 / CVS2.1 but OK in dbmail-2.0rc8 (?)
On Thu, 16 Sep 2004 13:30:04 -0400, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Has anyone noticed that IMAP LIST fails in current CVS2.0 / CVS2.1 but functions correctly in dbmail-2.0rc8? I just installed/removed each of the above while switching to the corresponding conf files. Before I explore further... has anyone else checked this? I haven't seen it.. strange. I haven't experienced anything weird today. What do the logs say? Ilja
