rawhide report: 20040109 changes

[Alexandre Oliva]

On Jan 12, 2004, Gijs Hollestelle <gijs at gewis.nl> wrote:

> Alexandre Oliva wrote:
>> No, I only read its docs, just did again, and I don't see that it
>> supports preauth imap.

> Sounds like /usr/libexec/dovecot/imap does what you mean:

Cool.  Looks like I didn't look at the docs hard enough :-)

Anyway, there's still a regression:

$ /usr/libexec/dovecot/imap
* PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED] Logged in as aoliva
0 select INBOX
imap(aoliva): Error: open(/var/spool/mail/aoliva.lock) failed: Permission deniedimap(aoliva): Error: file_lock_dotlock() failed with mbox file /var/spool/mail/aoliva: Permission denied
imap(aoliva): Error: open(/var/spool/mail/aoliva.lock) failed: Permission deniedimap(aoliva): Error: file_lock_dotlock() failed with mbox file /var/spool/mail/aoliva: Permission denied
0 NO Internal error [2004-01-12 17:06:26]

However, the regression may actually be a good thing.  To wit:

$ imapd
* PREAUTH [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] Pre-authenticated user aoliva free.redhat.lsd.ic.unicamp.br IMAP4rev1 2003.338rh at Mon, 12 Jan 2004 17:08:20 -0200 (BRST)
0 select INBOX
* 15 EXISTS
* NO Mailbox vulnerable - directory /var/spool/mail must have 1777 protection
[...]

Interesting...  I'd never seen this warning before, since fetchmail
didn't report it to me.  Fortunately, I only get this when running
imapd on my local mailbox (that is never read with imapd, so no
risk).  I sort of prefer dovecot's behavior of refusing access instead
of offering risky access, so, no actual regression from where I
stand.

But then, we should probably do something such that dovecot/imap
actually worked under these conditions.  Either revert to mode 1777
for /var/spool/mail/ (bad!) or make imap setgid mail (not so bad).

It should be possible to control the locking mechanisms used by it,
but I don't see how: libexec/dovecot doesn't even attempt to stat
/etc/dovecot.conf.  And, worse, it saves local state in ~/Mail/.imap.
This means that, whenever I rsync my ~/Mail/ dir to the mailbox server
(that happens to also be where I keep a live copy of my data),
anything that was saved there before is gone.  Now *that*'s bad.  It's
definitely not a drop-in replacement for UW-imap.

I guess I could live with that, but it can be more of a pain for users
that download e-mail from systems in which /var/spool/mail has safer
permissions.

Ideally, it should be possible to tell dovecot/imap which directory to
use instead of mail/.imap or Mail/.imap with some env var or cmd line
flag.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer