First things first: dmail vs. tmail.
tmail must be run as root; the program is designed to be invoked from a
process whose UID is not the destination user, and thus it needs root in
order to be able to setuid to the user and complete delivery.
If the delivery program is run as the destination user (e.g., procmail
does this), then you can use dmail instead of tmail. dmail is a variant
of tmail that runs as the destination user and MUST NOT run as root.
So, if you are worried about additional setuid root software AND the
delivery program runs as the destination user, then dmail is for you.
Now, on to your issue...
dmail and tmail both use a series of steps to determine what to use for
the INBOX. The full rules are complex, but they boil down to two things:
[1] the normal INBOX if dmail/tmail needs to create it
[2] the existing INBOX
Unmodified UW imapd sources set [1] to the traditional UNIX mailbox in the
spool directory. To change this, you should edit
imap-2007a/src/osdep/unix/Makefile
to change the definition of CREATEPROTO from unixproto to mixproto. The
"-b mix" flag in tmail is supposed to do this; in dmail you have to do the
Makefile edit (which is recommended in any case).
However, what comes up with [2] should override [1]. The tmail log that
you supplied indicates that tmail is not finding the mix INBOX nor, for
that matter, a traditional Unix INBOX, and thus it thinks that it must
create one.
What logs do you get with the "-b mix" with it setuid root?
Try rebuilding with the CREATEPROTO change noted above and send me the
tmail logs from that.
Once tmail is working OK, then consider deploying dmail in its place.
Note that with dmail, you can't use -b.
On Thu, 10 Apr 2008, Tom Leach wrote:
OK, I'm having issues with trying to get direct delivery to a mix formatted
inbox through postfix. I have been able to so far get postfix to deliver to
a unix formatted /var/mail inbox, but only then through a nasty hack (suid
root tmail, ain't happining on the production server!)
I then removed the /var/mail/<user> inbox, and created a ~user/INBOX with
mailutil create "#driver.mix/INBOX" but postfix still delivers to
/var/mail/<user> with #driver.unix/INBOX.
Anyone using postfix, tmail, and delivering directly to mbx/mix mailboxes?
If so, could you reply with your main.cf/master.cf tmail lines and any other
config pointers?
Thanks,
Tom Leach
[EMAIL PROTECTED]
The setup: RHEL 5, postfix 2.3.3 (tried 2.5 as well), /var/mail symlink to
/var/spool/mail with perm 1777, imapd 2007a1 (not dev).
postfix main.cf:
mailbox_transport = tmail
tmail_destination_recipient_limit = 1
postfix master.cf:
tmail unix - n n - - pipe
flags=DR eol=\r\n user=nobody argv=/usr/local/bin/tmail ${user}
also tried, but fail:
flags=DR eol=\r\n user=root argv=/usr/local/bin/tmail -b mix ${user}
flags=DR eol=\r\n user=nobody argv=/usr/local/bin/tmail -b mix ${user}
postfix wont let a pipe run as root, tmail won't allow -b if not root.
If I don't set tmail to suid root, then when delivery is attempted, I get the
following in /var/log/maillog (UID 1005 is my user, 99 is nobody):
Apr 10 15:15:05 galaxy4 tmail[3513]: unable to log in UID 1005 from UID 99
Apr 10 15:15:05 galaxy4 tmail[3513]: error in delivery
With tmail suid root, I get (wbr is the user):
Apr 10 15:53:39 galaxy4 tmail[3810]: delivering to wbr+INBOX
Apr 10 15:53:39 galaxy4 tmail[3810]: attempting to create mailbox
#driver.unix/INBOX path /var/spool/mail/wbr
Apr 10 15:53:39 galaxy4 tmail[3810]: created /var/spool/mail/wbr
Apr 10 15:53:39 galaxy4 tmail[3810]: Verifying safe delivery to
/var/spool/mail/wbr by UID 1005
Apr 10 15:53:39 galaxy4 tmail[3810]: unix appending to #driver.unix/INBOX
(file /var/spool/mail/wbr)
Apr 10 15:53:39 galaxy4 tmail[3810]: delivered to /var/spool/mail/wbr
Apr 10 15:53:39 galaxy4 tmail[3810]: Verifying safe delivery to
/var/spool/mail/wbr by UID 1005
Apr 10 15:53:39 galaxy4 tmail[3810]: all recipients delivered
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
