dmail, mbx, and mbox problems
Marc W
format (i.e. a big flat file) to mbx format and am looking for some
advice. We run Red Hat 7.3, use procmail for the delivery agent, and
have mailboxes in ~username/INBOX. I am using the imap utilities
(dmail, mailutil, tmail...) that come with UW's imap-2002.
I would like to tell procmail to use dmail to deliver mail and convert
user mailboxes one user at a time. From my reading of the dmail man
page, it seems that it should be able to autodetect the mailbox type
and call the correct driver to deliver the mail. However, in practice
this does not seem to be the case; it will only deliver to MBX style
mailboxes. When it encounters a regular unix mailbox it spits out the
following error message:
Dec 9 12:10:34 imap4 dmail[12772]: delivering to melancht+INBOX
Dec 9 12:10:34 imap4 dmail[12772]: Verifying safe delivery to
/home/faculty/nds
u/melancht/INBOX
Dec 9 12:10:34 imap4 dmail[12772]: dummy appending to
#driver.dummy/INBOX
(file /home/faculty/ndsu/melancht/INBOX)
Dec 9 12:10:34 imap4 dmail[12772]: Not a MBX-format mailbox: INBOX
Dec 9 12:10:34 imap4 dmail[12772]: message delivery failed to
/home/faculty/nds
u/melancht/INBOX
The same happens for an INBOX of 0 length. (In the build process I set
CREATEPROTO and EMPTYPROTO to mbxproto.)
My ~/.procmailrc looks like so:
VERBOSE=off
DEFAULT=$HOME/INBOX
:0 W
| /usr/local/bin/dmail $LOGNAME+INBOX
Am I right to expect that I can run dmail on a system with mixed
mailbox formats? If yes, have I missed some important configuration
step to allow for this? Any advice is appreciated.
--
Marc Wallman
North Dakota State University
Mark Crispin
> I would like to tell procmail to use dmail to deliver mail and convert
> user mailboxes one user at a time. From my reading of the dmail man
> page, it seems that it should be able to autodetect the mailbox type
> and call the correct driver to deliver the mail. However, in practice
> this does not seem to be the case; it will only deliver to MBX style
> mailboxes.
dmail will deliver to any format mailbox, unless of course you are running
hacked code.
> Dec 9 12:10:34 imap4 dmail[12772]: delivering to melancht+INBOX
This means that it is trying to deliver to user melancht's INBOX.
> Dec 9 12:10:34 imap4 dmail[12772]: Verifying safe delivery to /home/faculty/ndsu/melancht/INBOX
This means that there is a /home/faculty/ndsu/melancht/INBOX file.
> Dec 9 12:10:34 imap4 dmail[12772]: dummy appending to #driver.dummy/INBOX (file /home/faculty/ndsu/melancht/INBOX)
This means that /home/faculty/ndsu/melancht/INBOX is zero-length, and thus
has been farmed out to the dummy driver for action.
> Dec 9 12:10:34 imap4 dmail[12772]: Not a MBX-format mailbox: INBOX
This means that you defined EMPTYPROTO as mbxproto, saying that
zero-length files should be appended to as if they were mbx format. But
mbx files can not be zero-length; an empty mbx file is 2048 bytes with
specific content in those 2048 bytes.
> The same happens for an INBOX of 0 length. (In the build process I set
> CREATEPROTO and EMPTYPROTO to mbxproto.)
It is meaningless to set EMPTYPROTO to mbxproto, since mbx files can never
be empty. The only valid settings of EMPTYPROTO are unixproto, mmdfproto,
tenexproto, and mtxproto.
> Am I right to expect that I can run dmail on a system with mixed
> mailbox formats?
Yes
> If yes, have I missed some important configuration
> step to allow for this?
Yes you have. What you missed is the proper way to create an empty mbx
format INBOX file. "touch ~user/INBOX" is not the proper way. Try using
mailutil, e.g. "mailutil create #driver.mbx/~user/INBOX"
Also, revoke the bogus setting of EMPTYPROTO. The CREATEPROTO setting is
OK.
If you have made any other hacks, you may need to review them as well to
see if they are causing any bad effects.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Marc W
[snip]
> > Dec 9 12:10:34 imap4 dmail[12772]: Not a MBX-format mailbox: INBOX
>
> This means that you defined EMPTYPROTO as mbxproto, saying that
> zero-length files should be appended to as if they were mbx format. But
> mbx files can not be zero-length; an empty mbx file is 2048 bytes with
> specific content in those 2048 bytes.
>
> > The same happens for an INBOX of 0 length. (In the build process I set
> > CREATEPROTO and EMPTYPROTO to mbxproto.)
>
> It is meaningless to set EMPTYPROTO to mbxproto, since mbx files can never
> be empty. The only valid settings of EMPTYPROTO are unixproto, mmdfproto,
> tenexproto, and mtxproto.
Leaving the EMPTYPROTO variable untouched fixed the problem. Thanks!
Unfortunately, dmail is still not behaving as I expect. When I run it
out of the global procmailrc it insists on delivering to
/var/spool/mail/username rather than ~/INBOX where we have our
maildrops. I am invoking it in /etc/procmailrc like so:
:0 W
| /usr/local/bin/dmail $LOGNAME+INBOX
How does one resolve the ambiguity between INBOX referring to
/var/spool/mail/username and ~/INBOX? The meaning of the INBOX mail
folder seems to behave differently in different contexts (e.g. when I
put the above procmail rule to invoke dmail in ~/.procmailrc it drops
mail in ~/INBOX). Any thoughts?
Mark Crispin
> Unfortunately, dmail is still not behaving as I expect. When I run it
> out of the global procmailrc it insists on delivering to
> /var/spool/mail/username rather than ~/INBOX where we have our
> maildrops.
That is because you don't have an existing mbx-format INBOX in ~/INBOX,
and there is an existing mbox-format INBOX in /var/spool/mail/username.
> | /usr/local/bin/dmail $LOGNAME+INBOX
You don't need the $LOGNAME+INBOX since that is the default. Note that
dmail won't work unless the token to the left of the "+" is the same UID
as the process.
> How does one resolve the ambiguity between INBOX referring to
> /var/spool/mail/username and ~/INBOX?
INBOX refers to an mbx-format ~/INBOX if it exists.
Else INBOX refers to an mbox-format /usr/spool/mail/username if it exists.
Else INBOX refers to whatever would be created by CREATEPROTO as INBOX.
Marc W
> > How does one resolve the ambiguity between INBOX referring to
> > /var/spool/mail/username and ~/INBOX?
>
> INBOX refers to an mbx-format ~/INBOX if it exists.
> Else INBOX refers to an mbox-format /usr/spool/mail/username if it exists.
> Else INBOX refers to whatever would be created by CREATEPROTO as INBOX.
What happens in the event that ~/INBOX could be in either mbx or mbox
format? This is the case on my system. I'd like dmail to autodetect
the format of ~/INBOX and always deliver there.
What I've found is that if ~/INBOX is an mbx file dmail will put mail
there. If ~/INBOX is just a regular unix mailbox, or if ~/INBOX does
not exist, it will stick mail in /var/spool/mail/username. If
/var/spool/mail/username does not exist, it will create it as a
regular unix mailbox (even though I set CREATEPROTO=mbxproto in
src/osdep/unix/Makefile).
Mark Crispin
> What happens in the event that ~/INBOX could be in either mbx or mbox
> format? This is the case on my system. I'd like dmail to autodetect
> the format of ~/INBOX and always deliver there.
Sorry. That configuration is not supported, nor are there any plans to
support it.
~/INBOX is the designated name of an mbx-format INBOX, just as mail.txt is
for the legacy tenex-format and mbox for the legacy home-directory
traditional UNIX format.
Matters are complex enough now without adding further unnecessary
complexity.