[Dovecot] RC7: its issues or mine?

David Lee

21 Aug 2006 21 Aug '06

2:58 p.m.

Background: I'm new to dovecot (although with many years Washington IMAP behind me). We're considering migrating from Washington IMAP to dovecot on the main service here, and have just started trying dovecot, using RC7.

Washington, IMAP has the usual(-ish) "/var/spool/mail" shared area for the INBOX (trad. UNIX "From " format); a user's folders default to being in their home directory (same format). We are looking towards a "minimal effort" migration to dovecot, so wish to keep this layout. (In an ideal world, we would re-think, including "maildir" etc. But that's not an option at the moment.)

I have encountered three issues (so far); I'm not sure whether their mine or something in dovecot (if the latter, whether bugs or features; whether RC7-specific issues; etc.).

The overall description of "default_mail_env" seems inadequate (in the conf file, "doc/variables.txt" and "doc/mail-storages.txt"). I'm trying: default_mail_env = mbox:~:INBOX=/var/spool/mail/%-2.02i/%u:INDEX=/tmp/indexes/%d/%n

and that seems OK-ish. (The extra "%-2.02i" is because we subdivide the otherwise huge "/var/spool/mail/" directory using the user's uid-mod-100.) But the mere act of an IMAP "login" commands creates a directory (empty) with the liternal name of ~ (tilde). (An IMAP 'list "Mail" "*"' command successfully finds the usr folders in the 'Mail' subdirectory of the user's home directory.)

It's almost as if the 'default_mail_env' is telling it to create (literal) '~' before realising that this is shorthand (as in C-shell) for home directory.

We have some Pine usage in our UNIX cluster. Historically this has taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid the need for the password: pre-authentication etc. (Yes, we realise that 'rsh' has security issues.) But when I try making symlink "/etc/rimapd" point to "/usr/dovecot/sbin/dovecot" this fails: Error: Can't use SSL key file /etc/ssl/private/dovecot.pem: Permission denied

We have: /etc/ssl/certs/dovecot.pem (mode 444) /etc/ssl/private/dovecot.pem (mode 400) for the sake of secure-IMAP (port 993). But why does this come into the equation at all for this (none-SSL) "rsh ... /etc/rimapd" usage?

I was developing and testing this here at work using an account that I mostly use from home using Outlook Express. I was very careful (I think!) only to use the read-only "examine INBOX" command (not "select INBOX"). When I went home and tried it as usual (connecting to our production Washington IMAP service reading that INBOX). But OE showed all the email (including previously read) as "unread" (closed envelope icon). It seems that dovecot has done something to the message headers (even under "examine") that has worried OE. Any thoughts?

Finally any hints for NFS-based working? We have a farm of a few Fedora machines running the IMAP processes and the sendmail locally-delivery. Our current "/etc/fstab" NFS spec. for the INBOX area (on a NetApp) is: rw,noac,actimeo=0,vers=3,tcp,timeo=600,rsize=32768,wsize=32768,hard,intr,fg,nosuid

Any changes? Issues? Thinks to consider? Etc.

Many thanks.

: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

Show replies by date

Chris Wakelin

21 Aug 21 Aug

4:07 p.m.

David Lee wrote:

...

Background: I'm new to dovecot (although with many years Washington IMAP behind me). We're considering migrating from Washington IMAP to dovecot on the main service here, and have just started trying dovecot, using RC7.

We did this last year without the users noticing!

...

I have encountered three issues (so far); I'm not sure whether their mine or something in dovecot (if the latter, whether bugs or features; whether RC7-specific issues; etc.).

The overall description of "default_mail_env" seems inadequate (in the conf file, "doc/variables.txt" and "doc/mail-storages.txt"). I'm trying: default_mail_env = mbox:~:INBOX=/var/spool/mail/%-2.02i/%u:INDEX=/tmp/indexes/%d/%n

and that seems OK-ish. (The extra "%-2.02i" is because we subdivide the otherwise huge "/var/spool/mail/" directory using the user's uid-mod-100.) But the mere act of an IMAP "login" commands creates a directory (empty) with the liternal name of ~ (tilde). (An IMAP 'list "Mail" "*"' command successfully finds the usr folders in the 'Mail' subdirectory of the user's home directory.)

It's almost as if the 'default_mail_env' is telling it to create (literal) '~' before realising that this is shorthand (as in C-shell) for home directory.

Hmm. Could you try using "~/" or "%h" instead of "~"?

...

We have some Pine usage in our UNIX cluster. Historically this has taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid the need for the password: pre-authentication etc. (Yes, we realise that 'rsh' has security issues.) But when I try making symlink "/etc/rimapd" point to "/usr/dovecot/sbin/dovecot" this fails: Error: Can't use SSL key file /etc/ssl/private/dovecot.pem: Permission denied

Sounds yucky. I think the program you'd need to run is "/usr/dovecot/libexec/imap" rather than "dovecot" but you'll need to supply it some environment variables. I've never tried though.

One thing to watch though, is that you don't have any Pine 3.x users (as we had!) as it uses obsolete IMAP (v2!) commands not supported by Dovecot and they would have problems accessing folders.

...

I was developing and testing this here at work using an account that I mostly use from home using Outlook Express. I was very careful (I think!) only to use the read-only "examine INBOX" command (not "select INBOX"). When I went home and tried it as usual (connecting to our production Washington IMAP service reading that INBOX). But OE showed all the email (including previously read) as "unread" (closed envelope icon). It seems that dovecot has done something to the message headers (even under "examine") that has worried OE. Any thoughts?

Even "select INBOX" shouldn't have changed anything (at least not in mbox format), so this is very strange. I take it that OE is talking to the Washington IMAP server. Was OE connected at the time you did the "examine"? If so, I'd expect Washington to get a bit upset, probably just losing its "mailbox lock".

...

Finally any hints for NFS-based working? We have a farm of a few Fedora machines running the IMAP processes and the sendmail locally-delivery. Our current "/etc/fstab" NFS spec. for the INBOX area (on a NetApp) is: rw,noac,actimeo=0,vers=3,tcp,timeo=600,rsize=32768,wsize=32768,hard,intr,fg,nosuid

Not really. I'd guess as long as you include "dotlock" in the lock options for the MTA and dovecot, it should work OK. You probably don't need "mmap_disable = yes" as the mail spool is local to Dovecot.

...

Any changes? Issues? Thinks to consider? Etc.

Folder subscriptions may need migrating or tweaking and you probably need to do something with hidden namespaces to deal with the folder prefix.

Hope this helps, Chris

-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094

David Lee

4:43 p.m.

On Mon, 21 Aug 2006, Chris Wakelin wrote:

...

David Lee wrote:

...
[...] But the mere act of an IMAP "login" commands creates a directory (empty) with the liternal name of ~ (tilde). (An IMAP 'list "Mail" "*"' command successfully finds the usr folders in the 'Mail' subdirectory of the user's home directory.)

It's almost as if the 'default_mail_env' is telling it to create (literal) '~' before realising that this is shorthand (as in C-shell) for home directory.

Hmm. Could you try using "~/" or "%h" instead of "~"?

Yes, both these seem to cure it. Many thanks! (Is it documented, and thus did I miss it?)

...

...

We have some Pine usage in our UNIX cluster. Historically this has taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid the need for the password: pre-authentication etc. (Yes, we realise that 'rsh' has security issues.) But when I try making symlink "/etc/rimapd" point to "/usr/dovecot/sbin/dovecot" this fails: Error: Can't use SSL key file /etc/ssl/private/dovecot.pem: Permission denied

Sounds yucky. I think the program you'd need to run is "/usr/dovecot/libexec/imap" rather than "dovecot" [...]

Drat. Yes. My mistake. That's looking better, but it still fails...

...

[...] but you'll need to supply it some environment variables. I've never tried though.

... with an error message (which I'm line-wrapping here with "\"):

imap(<username>): Error: Ambiguous mail location setting, don't know
what to do with it: /var/spool/mail/<username> (try prefixing it
with mbox: or maildir:) imap( /var/spool/mail/<username>

So this mechanism not finding the "default_mail_env" (with our peculiar sub-dir specification) from the config file. Perhaps more likely it's not finding the config file itself at all.

How do other Pine-using sites handle the "rsh ... /etc/rimapd" issue?

...

One thing to watch though, is that you don't have any Pine 3.x users (as we had!) as it uses obsolete IMAP (v2!) commands not supported by Dovecot and they would have problems accessing folders.

Thanks for the heads-up. Our pine usage is relatively small; the only support we offer is for our own installation, which is 4.x . So this issue, if it crops up at all, ought to be broadly manageable.

(Thanks also for your other observations, which I'll work on.)

: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

Chris Wakelin

5:23 p.m.

David Lee wrote:

...

...
Hmm. Could you try using "~/" or "%h" instead of "~"?

Yes, both these seem to cure it. Many thanks! (Is it documented, and thus did I miss it?)

I think the examples had something like "~/mail" so I guess the "/" is needed for "~" to work. %h% and the other variables are documented in doc/variables.txt.

...

...
...

We have some Pine usage in our UNIX cluster. Historically this has taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid the need for the password: pre-authentication etc. (Yes, we realise that 'rsh' has security issues.) But when I try making symlink "/etc/rimapd" point to "/usr/dovecot/sbin/dovecot" this fails: Error: Can't use SSL key file /etc/ssl/private/dovecot.pem: Permission denied

Sounds yucky. I think the program you'd need to run is "/usr/dovecot/libexec/imap" rather than "dovecot" [...]

Drat. Yes. My mistake. That's looking better, but it still fails...

...
[...] but you'll need to supply it some environment variables. I've never tried though.

... with an error message (which I'm line-wrapping here with "\"):

imap(<username>): Error: Ambiguous mail location setting, don't know
what to do with it: /var/spool/mail/<username> (try prefixing it
with mbox: or maildir:) imap( /var/spool/mail/<username>

So this mechanism not finding the "default_mail_env" (with our peculiar sub-dir specification) from the config file. Perhaps more likely it's not finding the config file itself at all.

You'll need to supply it with at least MAIL=(the variable-substituted version of default_mail_env) and possibly some NAMESPACE* environment variables if the client uses a folder prefix. You'll also want some logging variables I guess; it won't be able to use the Dovecot master process for this, so you'll probably have to make it go to syslog (USE_SYSLOG="yes" SYSLOG_FACILITY="mail" etc.)

I'm not sure it's been documented properly yet, but Timo has mentioned this sort of thing for debugging purposes. In some ways the simplest thing is to grep through the src/imap/*.c code for "getenv". I'd be pretty surprised if anybody's tried this for Pine before!

Best Wishes, Chris

Timo Sirainen

8:37 p.m.

On Mon, 2006-08-21 at 15:58 +0100, David Lee wrote:

...

We have some Pine usage in our UNIX cluster. Historically this has taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid the need for the password: pre-authentication etc. (Yes, we realise that 'rsh' has security issues.) But when I try making symlink "/etc/rimapd" point to "/usr/dovecot/sbin/dovecot" this fails:

"dovecot --exec-mail imap" is the correct way to do this.

...

I was developing and testing this here at work using an account that I mostly use from home using Outlook Express. I was very careful (I think!) only to use the read-only "examine INBOX" command (not "select INBOX"). When I went home and tried it as usual (connecting to our production Washington IMAP service reading that INBOX). But OE showed all the email (including previously read) as "unread" (closed envelope icon). It seems that dovecot has done something to the message headers (even under "examine") that has worried OE. Any thoughts?

Not really.. Examine command does change the mbox headers (just as it does with UW-IMAP), but the changes should be fully compatible with UW-IMAP. The message is "unread" if it doesn't have "Status: R" header. Dovecot really shouldn't be removing any of those.

...

Finally any hints for NFS-based working? We have a farm of a few Fedora machines running the IMAP processes and the sendmail locally-delivery. Our current "/etc/fstab" NFS spec. for the INBOX area (on a NetApp) is: rw,noac,actimeo=0,vers=3,tcp,timeo=600,rsize=32768,wsize=32768,hard,intr,fg,nosuid

Any changes? Issues? Thinks to consider? Etc.

http://wiki.dovecot.org/NFS

Matthias Andree

22 Aug 22 Aug

7:44 a.m.

Timo Sirainen tss@iki.fi writes:

...

On Mon, 2006-08-21 at 15:58 +0100, David Lee wrote:

...

We have some Pine usage in our UNIX cluster. Historically this has taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid the need for the password: pre-authentication etc. (Yes, we realise that 'rsh' has security issues.) But when I try making symlink "/etc/rimapd" point to "/usr/dovecot/sbin/dovecot" this fails:

"dovecot --exec-mail imap" is the correct way to do this.

Could you document this in some prominent place, inside the package?

While this is shown on http://wiki.dovecot.org/CommandLine, I find it awkward to go online to check. While a Wiki is a good complement to share some cheats, may I ask for a complete documentation to ship with the Dovecot tarball? Some systems even have policies as to manual pages.

-- Matthias Andree

Charles Marcus

7:16 p.m.

Matthias Andree wrote:

...

Timo Sirainen tss@iki.fi writes:

...
On Mon, 2006-08-21 at 15:58 +0100, David Lee wrote:

...

We have some Pine usage in our UNIX cluster. Historically this has taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid the need for the password: pre-authentication etc. (Yes, we realise that 'rsh' has security issues.) But when I try making symlink "/etc/rimapd" point to "/usr/dovecot/sbin/dovecot" this fails: "dovecot --exec-mail imap" is the correct way to do this.

...

Could you document this in some prominent place, inside the package?

While this is shown on http://wiki.dovecot.org/CommandLine, I find it awkward to go online to check. While a Wiki is a good complement to share some cheats, may I ask for a complete documentation to ship with the Dovecot tarball? Some systems even have policies as to manual pages.

I find your attitude a bit demanding and unreasonable, Matthias, but maybe it is a language issue?

Dovecot is free software, so you are more than welcome to contribute to the project in any way you so choose, including documentation, so please, I'm sure Timo would appreciate the help.

Best regards,

Charles

Matthias Andree

24 Aug 24 Aug

2:55 a.m.

Charles Marcus CMarcus@Media-Brokers.com writes:

...

Matthias Andree wrote:

...
Timo Sirainen tss@iki.fi writes:

...
On Mon, 2006-08-21 at 15:58 +0100, David Lee wrote:

...

We have some Pine usage in our UNIX cluster. Historically this has taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid the need for the password: pre-authentication etc. (Yes, we realise that 'rsh' has security issues.) But when I try making symlink "/etc/rimapd" point to "/usr/dovecot/sbin/dovecot" this fails: "dovecot --exec-mail imap" is the correct way to do this.

...
Could you document this in some prominent place, inside the package?

While this is shown on http://wiki.dovecot.org/CommandLine, I find it awkward to go online to check. While a Wiki is a good complement to share some cheats, may I ask for a complete documentation to ship with the Dovecot tarball? Some systems even have policies as to manual pages.

I find your attitude a bit demanding and unreasonable, Matthias, but maybe it is a language issue?

Certainly not a language issue. It is a question and a hint beyond my own fancy.

...

Dovecot is free software, so you are more than welcome to contribute to the project in any way you so choose, including documentation, so please, I'm sure Timo would appreciate the help.

I have in fact already reworked some documents in the Wiki, and writing Dovecot documentation isn't my prime directive. I am involved in own OSS projects -- one of them happens to get the messages out of Dovecot. Go figure.

-- Matthias Andree

David Lee

31 Aug 31 Aug

3:13 p.m.

On Mon, 21 Aug 2006, Timo Sirainen wrote:

...

On Mon, 2006-08-21 at 15:58 +0100, David Lee wrote:

...

We have some Pine usage in our UNIX cluster. Historically this has taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid the need for the password: pre-authentication etc. (Yes, we realise that 'rsh' has security issues.) But when I try making symlink "/etc/rimapd" point to "/usr/dovecot/sbin/dovecot" this fails:

"dovecot --exec-mail imap" is the correct way to do this.

(Sorry for delay in replying: other things in the way for a few days.)

Many thanks for that hint. That seems to work nicely.

With uw-imap, "/etc/rimapd" is usually a symlink to imapd. But with dovecot, because of those extra arguments ("--exec-mail imap"), I ended up make "/etc/rimapd" a tiny shell fragment:

#! /bin/sh exec /usr/dovecot/sbin/dovecot --exec-mail imap

(The slightly unusual directory path is a purely local thing here...)

Is it in the WIKI? If not, can it be put in? By you? me? a.n.other?

...

...

I was developing and testing this here at work using an account that I mostly use from home using Outlook Express. I was very careful (I think!) only to use the read-only "examine INBOX" command (not "select INBOX"). When I went home and tried it as usual (connecting to our production Washington IMAP service reading that INBOX). But OE showed all the email (including previously read) as "unread" (closed envelope icon). It seems that dovecot has done something to the message headers (even under "examine") that has worried OE. Any thoughts?

Not really.. Examine command does change the mbox headers (just as it does with UW-IMAP), but the changes should be fully compatible with UW-IMAP. The message is "unread" if it doesn't have "Status: R" header. Dovecot really shouldn't be removing any of those.

Well, it didn't reproduce. Let's put this to one side for the moment with possible "pilot error". (I haven't got my dovecot wings yet!)

Many thanks.

: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

6607

Age (days ago)

6617

Last active (days ago)

List overview

8 comments

5 participants

participants (5)

Charles Marcus
Chris Wakelin
David Lee
Matthias Andree
Timo Sirainen