Mark, I didn't mention this before, but I had already changed the
CREATEPROTO to mixproto (but I left EMPTYPROTO as unixproto).
I can't run with the -b flag since postfix won't let a pipe have a
user=root argument, and even if tmail is suid root, it will fail when I
add the -b flag. The logs I supplied were both non-suid and suid tmail
to root.
Chuck, in the main.cf file, the comments around default_privs say to not
use a privileged user but I went ahead and tried setting it to root.
Postfix then refuses to start at all:
Apr 11 09:39:29 galaxy4 postfix[7769]: fatal: file /etc/postfix/main.cf:
parameter default_privs: user root has privileged user ID
Apr 11 09:39:30 galaxy4 postfix/sendmail[7771]: fatal: file
/etc/postfix/main.cf: parameter default_privs: user root has privileged
user ID
I'm a postfix newb (sendmail veteran) but I thought I would take a few
cracks at postfix since that seems to be the current rage. I'll try
using dmail since that doesn't need root access (but I'm not sure if I
can get the master.cf to run dmail as the destination user or just a
mail daemon user) and if that doesn't pan out, it's back to sendmail.
Postfix was working in delivering mbox format to /var/mail, I'm just
trying to hammer it to work with d/tmail and deliver to a home directory
based mix inbox.
Thanks!
Tom Leach
[EMAIL PROTECTED]
On 04/10/2008 05:06 PM, Mark Crispin wrote:
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
[email protected]
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
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
