Mailing List Archive

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.c 2004-03-20
13:42:03.000000000 +0100
+++ dbmail-2.1/main.c 2004-03-20 13:43:19.000000000 +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:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
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.c 2004-03-20
> 13:42:03.000000000 +0100
> +++ dbmail-2.1/main.c 2004-03-20 13:43:19.000000000 +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: rc4 serious bug in dbmail-smtp [ In reply to ]
Serious, yes, but show stopper, no... that mail is delivered and is not lost.

Definitely my fault, though. That looks exactly like a diff I had between two
versions of main.c I had been working on when I realized that I'd duplicated
my own work into two separate trees. *oops*.

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.

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.c 2004-03-20
> > 13:42:03.000000000 +0100
> > +++ dbmail-2.1/main.c 2004-03-20 13:43:19.000000000 +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: rc4 serious bug in dbmail-smtp [ In reply to ]
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.c 2004-03-20
>>>13:42:03.000000000 +0100
>>>+++ dbmail-2.1/main.c 2004-03-20 13:43:19.000000000 +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: rc4 serious bug in dbmail-smtp [ In reply to ]
Ok, try this out. Adds all of the arguments to the usage message, adds the
extra loop for the mailbox selection, adds config file selection, and changes
the ill-chosen argument -f, for "from" to -r, "return" since -f is used
elsewhere for the config file.

Ilja: I'm not on my devel box for a few days, so if the patch works out,
please commit it to CVS!

Aaron


Paul J Stevens <paul@nfg.nl> said:

>
> 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.c 2004-03-20
> >>>13:42:03.000000000 +0100
> >>>+++ dbmail-2.1/main.c 2004-03-20 13:43:19.000000000 +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
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
On Sun, 2004-03-21 at 04:13, Aaron Stone wrote:
> Ok, try this out. Adds all of the arguments to the usage message, adds the
> extra loop for the mailbox selection, adds config file selection, and changes
> the ill-chosen argument -f, for "from" to -r, "return" since -f is used
> elsewhere for the config file.
>
> Ilja: I'm not on my devel box for a few days, so if the patch works out,
> please commit it to CVS!

Cool! Thanks Aaron, after a quick patch and recompile, it's working
fine for me.
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Aaron Stone wrote:

> Ok, try this out. Adds all of the arguments to the usage message, adds the
> extra loop for the mailbox selection, adds config file selection, and changes
> the ill-chosen argument -f, for "from" to -r, "return" since -f is used
> elsewhere for the config file.
Patched, tested and commited :)

I've also updated the dbmail-smtp manpage. I'll take a better look at
the other manpages later on, unless somebody else likes to do that.

By the way, by using getopt() some behaviour has changed:
dbmail-smtp -d ilja1@example.com ilja2@example.com
does not work anymore, it's now:
dbmail-smtp -d ilja1@example.com -d ilja2@example.com

I've also put this in the manpage. Seems like logical behaviour to me :)
>
> Ilja: I'm not on my devel box for a few days, so if the patch works out,
> please commit it to CVS!
Done

Ilja
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Ilja Booij wrote:
> dbmail-smtp -d ilja1@example.com -d ilja2@example.com
>
> I've also put this in the manpage. Seems like logical behaviour to me :)
Logical behaviour: not the fact that I put it in the manpage, but the
fact that one can use multiple -d options.. ;)

Ilja
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Well, nice to know that getopt is not working as advertised :-(

Take a look in main.c, and I have a note in a comment right above getopt()
explaining how it should return the char value of '1' for any argv elements
that are not preceeded by a recognized argument characters. The getopt()
processing loop is written specifically to handle this...

Ok, just did some testing. Apparently the test right below getopt() should be:

if (c == 1)
c = c_prev

Note the removal of the single quotes. The manpage says:

If the first character of optstring is `-', then each
non-option argv-element is handled as if it were the argument
of an option with character code 1. (This is used by programs
that were written to expect options and other argv-elements
in any order and that care about the ordering of the two.)

I figured that this meant '1', the character code *of* 1. But no, just 1 :-P

Aaron


Ilja Booij <ilja@ic-s.nl> said:

>
> Ilja Booij wrote:
> > dbmail-smtp -d ilja1@example.com -d ilja2@example.com
> >
> > I've also put this in the manpage. Seems like logical behaviour to me :)
> Logical behaviour: not the fact that I put it in the manpage, but the
> fact that one can use multiple -d options.. ;)
>
> Ilja
>
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Aaron Stone wrote:

> Well, nice to know that getopt is not working as advertised :-(
>
> Take a look in main.c, and I have a note in a comment right above getopt()
> explaining how it should return the char value of '1' for any argv elements
> that are not preceeded by a recognized argument characters. The getopt()
> processing loop is written specifically to handle this...
>
> Ok, just did some testing. Apparently the test right below getopt() should be:
>
> if (c == 1)
> c = c_prev
>
> Note the removal of the single quotes. The manpage says:
>
> If the first character of optstring is `-', then each
> non-option argv-element is handled as if it were the argument
> of an option with character code 1. (This is used by programs
> that were written to expect options and other argv-elements
> in any order and that care about the ordering of the two.)
>
> I figured that this meant '1', the character code *of* 1. But no, just 1 :-P
I'd also say "character code 1" would mean '1'.. But the people who've
written the manpage probably disagree ;)

OK, applied and commited, and works :)

Ilja
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Hi

Paul J Stevens wrote:

> 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've been thinking about the same thing. Earlier on, I've made some
simple python scripts using imaplib and poplib to check if everything
functions well. The problem was that I did not really find any problems
that I or somebody else later discovered by accident. This could also be
due to my scripts being too simplistic of course :)

It might be a good idea if we come up with a nice test suite.
>
> 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.
I haven't looked at the LDAP in a while. As far as I can see, LDAP is
not nearly finished and/or stable. We have to take a good look at how
the data in LDAP should interact with the data in the SQL database. For
now, I can see a problem regarding the calculation of the mailsize of a
user. This is now done using fields in the users table, with some nice
joins with the mailboxes, messages and physmessage tables. When using
LDAP, this cannot be done. There are bound to be more problems. In fact,
every query outside in db.c that uses the users table is suspect.

I think we have to move to a system were we have a users table with some
things like curmail_size, but have all non-so-often-mutated data in a
different table, or in LDAP (or possibly even flat files).

This way, we have no problems with foreign keys in SQL. Also, it takes
care of not having to write the curmail_size to LDAP on every mutation
of the mailboxes (insert, append, delete etc).

>
> 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.
How does it become confused?
>
> You mean to say 'dbmail-smtp -m somefolder -u joe -u jane' would then be
> valid ?
This is completely valid right now. It sends mail for joe and jane to
their folder named somefolder (which is created if it does not exist yet)

Ilja
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Ilja Booij wrote:
>> 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.
>
> How does it become confused?

As in totally unresponsive. A kill and restart is all that helps.

--
________________________________________________________________
Paul Stevens paul@nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Paul J Stevens wrote:

> Ilja Booij wrote:
>
>>> 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.
>>
>>
>> How does it become confused?
>
>
> As in totally unresponsive. A kill and restart is all that helps.
That's what you'd call confused..

I'll try to reproduce the problem here.

Ilja
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Paul J Stevens wrote:
> Ilja Booij wrote:
>
>>> 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.
>>
>>
>> How does it become confused?
>
>
> As in totally unresponsive. A kill and restart is all that helps.

I reproduced the problem :)

1 change I made in imapcommand.c is to add '\r\n' to some server
messages, which seems to have helped.

I've seen another problem though: FETCH can also store the SEEN. I
wonder if we should return a NO to the fetch command, or that it should
return OK but not set the flag..

Ilja
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Ilja Booij wrote:
> Paul J Stevens wrote:
>
>> Ilja Booij wrote:
>>
>>>> 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.
>>>
>>>
>>>
>>> How does it become confused?
>>
>>
>>
>> As in totally unresponsive. A kill and restart is all that helps.
>
>
> I reproduced the problem :)
>
> 1 change I made in imapcommand.c is to add '\r\n' to some server
> messages, which seems to have helped.
>
> I've seen another problem though: FETCH can also store the SEEN. I
> wonder if we should return a NO to the fetch command, or that it should
> return OK but not set the flag..
I've made this change, it seems to work.
But, it seems as though Mozilla and Apple Mail don't like ACLs.. If a
client has only Read and Lookup rights, it still tries to do a
Store \Seen on the message. This of course fails! Strange that the
client still tries to do it.

When viewing the folder properties, the correct rights are listed.

Ilja


When I set
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
Ilja Booij wrote:
> I've made this change, it seems to work.
> But, it seems as though Mozilla and Apple Mail don't like ACLs.. If a
> client has only Read and Lookup rights, it still tries to do a
> Store \Seen on the message. This of course fails! Strange that the
> client still tries to do it.
>
> When viewing the folder properties, the correct rights are listed.

BTW, the Mozilla 1.6 works mostly. It does not try tp set the \Seen
flag, but it still sets the mail to Seen in the GUI (Which isn't much of
a problem, because it's still seen as NOT \Seen by other clients)

Another thing: The shared folder stuff does NOT work with Evolution 1.4.
I can see the mailbox in the folder listing, and even see the number of
unread messages (so STATUS also works), but I cannot select the mailbox.
Why this is the case is unclear to me at the moment. I guess I'll need
to do some ngrep-ing

Ilja
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
On Tue, 2004-03-23 at 08:02, Ilja Booij wrote:

>
> Another thing: The shared folder stuff does NOT work with Evolution 1.4.
> I can see the mailbox in the folder listing, and even see the number of
> unread messages (so STATUS also works), but I cannot select the mailbox.
> Why this is the case is unclear to me at the moment. I guess I'll need
> to do some ngrep-ing
>


Also, rather than using ngrep, you can start mozilla from the command
line after executing:

export CAMEL_VERBOSE_DEBUG=1

and it will display ALL the pop/imap/smtp traffic in the terminal
window. I pretty much always run my copy in this manner to look for
problems.

Also going back to a previous message, there is a mailing list for the
imap protocol that Mark Crispin reads regularly
(imap@u.washington.edu). It might be best to go directly to the source
to see whether a NO, BAD, or OK without doing the action is appropriate
for a certain circumstance since RFC's can be at times, rather
ambiguous.

Ryan Butler
ADI Internet Solutions
rbutler@adiis.net
Re: rc4 serious bug in dbmail-smtp [ In reply to ]
On Tue, 2004-03-23 at 08:59, Ryan Butler wrote:

> Also, rather than using ngrep, you can start mozilla from the command
> line after executing:
>

I obviously meant evolution, gah. :)

> export CAMEL_VERBOSE_DEBUG=1


Ryan Butler
ADI Internet Solutions
rbutler@adiis.net