Re: [Dbmail-dev] Time Zone
Paul F. De La Cruz wrote: RFC-3501 (IMAP4rev1) says... 2.3.3. Internal Date Message Attribute The internal date and time of the message on the server. This is not the date and time in the [RFC-2822] header, but rather a date and time which reflects when the message was received. In the case of messages delivered via [SMTP], this SHOULD be the date and time of final delivery of the message as defined by [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY command, this SHOULD be the internal date and time of the source message. In the case of messages delivered by the IMAP4rev1 APPEND command, this SHOULD be the date and time as specified in the APPEND command description. All other cases are implementation defined. So I'm figuring that means local to the server. I'm wondering if the mail client is supposed to be dealing with the offsets or what. Seems if it was given in GMT, then the mail client should just compensate for the time zone the person is in? What mail client are you using Blake? It looks likes the people who wrote the rfc assumed the server would always be in the same time zone as the client... We've had the same kind of trouble here, but even worse..: Apple Mail (Mac OS X) would always display the Internal Data one hour in the future. So a message arriving at 10:00AM would be displayed as having arrived at 11:00AM. What seems to be the problem in this case is that Apple Mail decided that mailservers should all have GMT internal time (we're at GMT+1 here), and should compensate for that itself (without the possibility of changing, unless you'd want to set the timezone zone to GMT for your whole desktop...) Anyway, switching to Mozilla Thunderbird fixed the problem :) To conclude, I guess this is a pretty fundamental problem, which cannot simply be dealt with by changing the timezone to GMT on your server, because that will break some clients that are happily working right now. Ilja
Re: [Dbmail-dev] Time Zone
Ilja Booij [EMAIL PROTECTED] said: Paul F. De La Cruz wrote: RFC-3501 (IMAP4rev1) says... 2.3.3. Internal Date Message Attribute The internal date and time of the message on the server. This is not the date and time in the [RFC-2822] header, but rather a date and time which reflects when the message was received. In the case of messages delivered via [SMTP], this SHOULD be the date and time of final delivery of the message as defined by [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY command, this SHOULD be the internal date and time of the source message. In the case of messages delivered by the IMAP4rev1 APPEND command, this SHOULD be the date and time as specified in the APPEND command description. All other cases are implementation defined. So I'm figuring that means local to the server. I'm wondering if the mail client is supposed to be dealing with the offsets or what. Seems if it was given in GMT, then the mail client should just compensate for the time zone the person is in? What mail client are you using Blake? It looks likes the people who wrote the rfc assumed the server would always be in the same time zone as the client... We've had the same kind of trouble here, but even worse..: Apple Mail (Mac OS X) would always display the Internal Data one hour in the future. So a message arriving at 10:00AM would be displayed as having arrived at 11:00AM. What seems to be the problem in this case is that Apple Mail decided that mailservers should all have GMT internal time (we're at GMT+1 here), and should compensate for that itself (without the possibility of changing, unless you'd want to set the timezone zone to GMT for your whole desktop...) Anyway, switching to Mozilla Thunderbird fixed the problem :) To conclude, I guess this is a pretty fundamental problem, which cannot simply be dealt with by changing the timezone to GMT on your server, because that will break some clients that are happily working right now. Ilja Is it possible that the times can all be marked as GMT, and that local server time, when used to stamp received messages, also be converted to GMT? That way, it becomes entirely encumbent upon the mail client to show the GMT date in the user's local time. IIRC, the time format specified by RFC 2/822 has an optional time zone field (haven't read it recently, though). Aaron --
[Dbmail-dev] rc4 serious bug in dbmail-smtp
Hi all,
I'm busy testing rc4, and I think I found a show-stopper.
Looks like delivery to mailboxes doesn't work. All mail gets delivered
to INBOX.
When I do 'cat testmail|/usr/sbin/dbmail-smtp -m Trash -u pablo' mail
gets delivered to INBOX.
As far as I can tell, deliver_to_mailbox is assigned in main.c, but
never used.
A simple/dirty patch that solves the problem but makes dbmail-smtp
dependant on the order of options (like 1.2):
diff -urNad /usr/src/dbmail/dbmail-2.0/dbmail-2.1/main.c dbmail-2.1/main.c
--- /usr/src/dbmail/dbmail-2.0/dbmail-2.1/main.c2004-03-20
13:42:03.0 +0100
+++ dbmail-2.1/main.c 2004-03-20 13:43:19.0 +0100
@@ -165,6 +165,9 @@
dsnuser_init(dsnuser);
dsnuser.address = strdup(optarg);
+if (deliver_to_mailbox) {
+ dsnuser.mailbox =
strdup(deliver_to_mailbox);
+ }
/* Add argument onto the users list. */
if (list_nodeadd
--
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] Time Zone
reply below.. :D On Sat, Mar 20, 2004 at 10:38:06AM -, Aaron Stone wrote: Ilja Booij [EMAIL PROTECTED] said: Paul F. De La Cruz wrote: RFC-3501 (IMAP4rev1) says... 2.3.3. Internal Date Message Attribute The internal date and time of the message on the server. This is not the date and time in the [RFC-2822] header, but rather a date and time which reflects when the message was received. In the case of messages delivered via [SMTP], this SHOULD be the date and time of final delivery of the message as defined by [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY command, this SHOULD be the internal date and time of the source message. In the case of messages delivered by the IMAP4rev1 APPEND command, this SHOULD be the date and time as specified in the APPEND command description. All other cases are implementation defined. So I'm figuring that means local to the server. I'm wondering if the mail client is supposed to be dealing with the offsets or what. Seems if it was given in GMT, then the mail client should just compensate for the time zone the person is in? What mail client are you using Blake? It looks likes the people who wrote the rfc assumed the server would always be in the same time zone as the client... We've had the same kind of trouble here, but even worse..: Apple Mail (Mac OS X) would always display the Internal Data one hour in the future. So a message arriving at 10:00AM would be displayed as having arrived at 11:00AM. What seems to be the problem in this case is that Apple Mail decided that mailservers should all have GMT internal time (we're at GMT+1 here), and should compensate for that itself (without the possibility of changing, unless you'd want to set the timezone zone to GMT for your whole desktop...) Anyway, switching to Mozilla Thunderbird fixed the problem :) To conclude, I guess this is a pretty fundamental problem, which cannot simply be dealt with by changing the timezone to GMT on your server, because that will break some clients that are happily working right now. Ilja Is it possible that the times can all be marked as GMT, and that local server time, when used to stamp received messages, also be converted to GMT? That way, it becomes entirely encumbent upon the mail client to show the GMT date in the user's local time. IIRC, the time format specified by RFC 2/822 has an optional time zone field (haven't read it recently, though). Aaron Yep, GMT is specified as + hmm... interesting idea.
Re: [Dbmail-dev] rc4 serious bug in dbmail-smtp
I'm seeing the same thing here
On Sat, 2004-03-20 at 07:48, Paul J Stevens wrote:
Hi all,
I'm busy testing rc4, and I think I found a show-stopper.
Looks like delivery to mailboxes doesn't work. All mail gets delivered
to INBOX.
When I do 'cat testmail|/usr/sbin/dbmail-smtp -m Trash -u pablo' mail
gets delivered to INBOX.
As far as I can tell, deliver_to_mailbox is assigned in main.c, but
never used.
A simple/dirty patch that solves the problem but makes dbmail-smtp
dependant on the order of options (like 1.2):
diff -urNad /usr/src/dbmail/dbmail-2.0/dbmail-2.1/main.c dbmail-2.1/main.c
--- /usr/src/dbmail/dbmail-2.0/dbmail-2.1/main.c2004-03-20
13:42:03.0 +0100
+++ dbmail-2.1/main.c 2004-03-20 13:43:19.0 +0100
@@ -165,6 +165,9 @@
dsnuser_init(dsnuser);
dsnuser.address = strdup(optarg);
+if (deliver_to_mailbox) {
+ dsnuser.mailbox =
strdup(deliver_to_mailbox);
+ }
/* Add argument onto the users list. */
if (list_nodeadd
Re: [Dbmail-dev] Time Zone
What's the proper netiquette for this? Zap the replies deeper than 2 or 3 ''s or just keep leaving notes at the top that the real message is at the end of the yellow brick road? Perhaps we could all agree to reply on top... ;-) Aaron Paul F. De La Cruz [EMAIL PROTECTED] said: reply below.. :D On Sat, Mar 20, 2004 at 10:38:06AM -, Aaron Stone wrote: Ilja Booij [EMAIL PROTECTED] said: Paul F. De La Cruz wrote: RFC-3501 (IMAP4rev1) says... 2.3.3. Internal Date Message Attribute The internal date and time of the message on the server. This is not the date and time in the [RFC-2822] header, but rather a date and time which reflects when the message was received. In the case of messages delivered via [SMTP], this SHOULD be the date and time of final delivery of the message as defined by [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY command, this SHOULD be the internal date and time of the source message. In the case of messages delivered by the IMAP4rev1 APPEND command, this SHOULD be the date and time as specified in the APPEND command description. All other cases are implementation defined. So I'm figuring that means local to the server. I'm wondering if the mail client is supposed to be dealing with the offsets or what. Seems if it was given in GMT, then the mail client should just compensate for the time zone the person is in? What mail client are you using Blake? It looks likes the people who wrote the rfc assumed the server would always be in the same time zone as the client... We've had the same kind of trouble here, but even worse..: Apple Mail (Mac OS X) would always display the Internal Data one hour in the future. So a message arriving at 10:00AM would be displayed as having arrived at 11:00AM. What seems to be the problem in this case is that Apple Mail decided that mailservers should all have GMT internal time (we're at GMT+1 here), and should compensate for that itself (without the possibility of changing, unless you'd want to set the timezone zone to GMT for your whole desktop...) Anyway, switching to Mozilla Thunderbird fixed the problem :) To conclude, I guess this is a pretty fundamental problem, which cannot simply be dealt with by changing the timezone to GMT on your server, because that will break some clients that are happily working right now. Ilja Is it possible that the times can all be marked as GMT, and that local server time, when used to stamp received messages, also be converted to GMT? That way, it becomes entirely encumbent upon the mail client to show the GMT date in the user's local time. IIRC, the time format specified by RFC 2/822 has an optional time zone field (haven't read it recently, though). Aaron Yep, GMT is specified as + hmm... interesting idea. ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev --
Re: [Dbmail-dev] SORT Problem - first patch for sort command ***VERY ALPHA***
ALl, Well people, attached is the first attempt, this code works for the SORT options required for my customers webmail system it will need some enhancment to fully follow the rfc draft for the SORT extention, It does subject,to,cc,from and arrival. Arrival was the easiest so it works perfectly, the others involved a new merge sort I added to list.c and obviously pulling all the headers in a mailbox which blows as far as performance. I would like to warn everyone while this code works it is no where near ready to go into any environment without a lot more help. But I needed to get it going so here it is. Please feel free to help/give comments and sugestions. For this first version I used a high perfomance merge sort I found with a relativly compatible grant on the licence. If anyone has a singly-link list merge sort or other better performing sort that is compatiable with the list.c code I would like to see options. A requirment for the sorting of header fields is the header caching I don't see this working with any kind of speed without it. Thanks, Leif p.s. a sample of the sort commands I used for testing would be A001 LOGIN username password A002 select INBOX A003 SORT (ARRIVAL) ISO-8859-1 ALL p.p.s. see http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.txt Yay!!! You are a life saver Leif. SB Leif Jackson [EMAIL PROTECTED] wrote: This observation was made before :) SORT and THREAD will have to be implemented for version 2.1 Or as a patch to 2.0 if I can get it done shortly, I really need it for our application which is a web based mail desktop system. So my client is asking for this almost every day. I hope to have something by next week:) -leif Ilja Sanjiv Bawa wrote: I tried a larger mailbox in OpenGroupware. It is way to slow It takes 8-10 seconds for a mailbox 200 messages. Cyrus does it instantaneously. It makes sense. OpenGroupware does not have a local repository (just as SquirrelMail does not - or any other web mail program). Folks, the SORT problem seems to be a show stopper for web mail implementations. I cant imagine this would be difficult to implement. Ultimately it is an ORDER BY on the SQL statement. I dont know what is involved on the IMAP side. This does not appear to be a big deal for Outlook/Express since they have local repositories and sorts can be done locally efficiently. Do you Yahoo!? Yahoo! Search - Find what youre looking for faster. ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev dbmail-2.0cvs031804-ic_sort.diff Description: Binary data
Re: [Dbmail-dev] rc4 serious bug in dbmail-smtp
Aaron Stone wrote:
Serious, yes, but show stopper, no... that mail is delivered and is not lost.
I would still call it a show stopper in terms of final release, because
it would cause both users and system administrators who rely on this
feature major headaches when suddenly inboxes are swamped by messages
normally filtered out into other folders.
I've been thinking about what kind of QA we can offer in the future. Is
something like unit-testing feasible ? I come from a python background,
and we never build stuff anymore without a test-framework. Also, an
expect(1) based test setup for the daemons would also be a boon, I think.
I'm planning to test the ldap-auth module over the next week. Has anyone
done so already? If so, what is the status of:
- ldap account creation and maintenance using dbmail-adduser.
- authentication and delivery.
Especially the latter should be well testing imo before release. Account
maintenance can be done through other means, but without authentication
and delivery I won't even bother building packages with ldap enabled.
Also, thunderbird now performs adequately with Ilja's acl fix. But
connections are still quite flakey. I still see massive numbers of EPIPE
errors in the syslog. A typical sequence reads:
Mar 20 15:42:50 tsuki dbmail/imap4d[32195]: PerformChildTask(): incoming
connection from [172.16.3.2]
Mar 20 15:42:50 tsuki dbmail/imap4d[32195]: COMMAND: [1 authenticate login]
Mar 20 15:42:51 tsuki dbmail/imap4d[32195]: IMAPD [PID 32195]: user (id
5, name someuser) login accepted @ 2004-03-20 15:42:51^M
Mar 20 15:42:51 tsuki dbmail/imap4d[32195]: COMMAND: [2 STATUS
somefolder (UIDNEXT MESSAGES UNSEEN RECENT)]
Mar 20 15:42:51 tsuki dbmail/imap4d[32195]: COMMAND: [2]
Mar 20 15:42:51 tsuki dbmail/imap4d[32195]: IMAPClientHandler(): error
[Broken pipe] on write-stream
And this is repeated over and over for each mailbox checked. And it
means thunderbird is unable to check all folders for unread email with
option: user_pref(mail.check_all_imap_folders_for_new, true);
And finally, I've done some testing on shared folders. When I set the
ACL lookup and read flags, but not the seen flag (which is a use-case I
use as a selling point for dbmail; office-manager sets read flags on
incoming mail only after an issue has been assigned to a co-worker,
while the co-workers can only read and download mail), thunderbird
becomes very confused.
One of the main reasons for using getopt() is to avoid rigid argument
orderings. There was *supposed* to be an extra test to see if the variable
delivery_to_mailbox is non-null, and if so, to loop through the dsnusers list
and set the destination mailbox correctly.
You mean to say 'dbmail-smtp -m somefolder -u joe -u jane' would then be
valid ?
There's another fix I'd like to make, which is both to document the '-f
return_path' argument and to change it to be '-r return_path' because
elsewhere there is an argument '-f config_file' -- that should be made into a
universal argument for all of the main()'s.
Aaron
Matthew T. O'Connor matthew@zeut.net said:
I'm seeing the same thing here
On Sat, 2004-03-20 at 07:48, Paul J Stevens wrote:
Hi all,
I'm busy testing rc4, and I think I found a show-stopper.
Looks like delivery to mailboxes doesn't work. All mail gets delivered
to INBOX.
When I do 'cat testmail|/usr/sbin/dbmail-smtp -m Trash -u pablo' mail
gets delivered to INBOX.
As far as I can tell, deliver_to_mailbox is assigned in main.c, but
never used.
A simple/dirty patch that solves the problem but makes dbmail-smtp
dependant on the order of options (like 1.2):
diff -urNad /usr/src/dbmail/dbmail-2.0/dbmail-2.1/main.c dbmail-2.1/main.c
--- /usr/src/dbmail/dbmail-2.0/dbmail-2.1/main.c2004-03-20
13:42:03.0 +0100
+++ dbmail-2.1/main.c 2004-03-20 13:43:19.0 +0100
@@ -165,6 +165,9 @@
dsnuser_init(dsnuser);
dsnuser.address = strdup(optarg);
+if (deliver_to_mailbox) {
+ dsnuser.mailbox =
strdup(deliver_to_mailbox);
+ }
/* Add argument onto the users list. */
if (list_nodeadd
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Re: [Dbmail-dev] Time Zone
That might be a good idea... I'd generally been taking the course of action the last person took. :D So if the last person answered at the bottom, then I answered at the bottom. If they answered inline, then I might answer inline. If they answer at the top, I'd answer at the top. I'm not sure if there is a proper netiquette for this really. Aside from I'd try to cut out too many signature lines to keep the messages shorter :D Paul F. De La Cruz On Sat, Mar 20, 2004 at 06:01:26PM -, Aaron Stone wrote: What's the proper netiquette for this? Zap the replies deeper than 2 or 3 ''s or just keep leaving notes at the top that the real message is at the end of the yellow brick road? Perhaps we could all agree to reply on top... ;-) Paul F. De La Cruz [EMAIL PROTECTED] said: reply below.. :D
Re: [Dbmail-dev] Time Zone
On Sat, 2004-03-20 at 13:01, Aaron Stone wrote: What's the proper netiquette for this? Zap the replies deeper than 2 or 3 ''s or just keep leaving notes at the top that the real message is at the end of the yellow brick road? Perhaps we could all agree to reply on top... ;-) I prefer to reply below the text (as evidenced by this message) since it flows more naturally, however I think the proper netiquette is to only include relevant text. If people need to see the earlier history of a thread, they can look in the earlier emails. Matthew
