There's a new version of maildrop available: 1.8.0 (01-Jan-2005) Check: http://www.courier-mta.org/maildrop/ An update in portage would be keen. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I'll take care of it
In CVS. Thanks Cheers, Ferdy
Be warned, maildrop version 1.8 requires the Courier Authentication library in order to support MySql and Ldap. The current ebuild does not account for this. Anyone who uses the stable branch won't have a problem with 1.7 .
Yes... Scott Taylor (gentoo developer) sent me a testing ebuild that adds this authlib stuff for mysql and ldap. Anyway thats the reason it is not on ARCH. I hope I have some free time this night to finish testing Scott's ebuild and commit it. Thanks for reporting. Ferdy
I reopen till I commit Scott's ebuild.
http://dev.gentoo.org/~ferdy/overlay/mail-filter/maildrop/maildrop-1.8.0-r1.ebuild That's the ebuild I'm working on. I've tested it and seems to work fine. I'll commit it today or tomorrow. If you see any problems with it, feel free to coment them here. Cheers, Ferdy
I just have a question: Courier Authentication Library is already in portage as a seperate ebuild, shouldn't maildrop use it rather than compiling courier authlib again?
Thats what that ebuild does. It depends on courier-authlib. Cheers, Ferdy
My mistake then, sorry.
maildrop-1.8.0-r1 is on CVS. Give it a while to propagate to rsync mirrors. Thanks. Ferdy
Hello again. -r1 compiles fine, but I have a problem. I use maildrop as the transport in postfix, not as local delivery agent. That means that maildrop runs in delivery mode. But this is what happens: ERR: authdaemon: s_connect() failed: Permission denied If I try this command: maildrop -d user@domain.com -V from root prompt, it works. If I try as user vmail (the user all virtual mail belongs to), I get the above error. It seems that the courier-authlib does not take request from any user other that root. Is this a maildrop bug? Should it request the info before switching uid?
Hmm, I think I found the solution. If set maildrop to uid (permition 4755) it works then. I think you should set it but default in the ebuild.
courier-authlib will allow to connect to every user in the mail group and the mail user itself. I guess you're using this scheme: http://www.postfix.org/MAILDROP_README.html#direct You either add the 'vmail' user to the 'mail' group or tell postfix to use the 'mail' user to run maildrop instead of 'vmail'. Setting maildrop suid root is a BadThing(TM). Tell me if it works for you. Cheers, Ferdy
Unfortunately it didn't work. I got this in the logs: Feb 13 21:26:08 [postfix/pipe] 368A6F015B: to=<user@somedomain.com>, relay=maildrop, delay=8, status=deferred (temporary failure. Command output: terminate called after throwing an instance of 'char const*' maildrop: signal 0x06 )
Which one did you try ? Adding vmail to mail or setting postfix to use mail to call maildrop ? Cheers, Ferdy
Actually, I tried both methods, alone and in combination. The same error everytime.
Could you run it with -V 4 to see where does it fail ? Thanks Ferdy
This is what I get: cca@defiant ~ $ maildrop -d cca@cca.dynalias.com -V 4 maildrop: authlib: groupid=1009 maildrop: authlib: userid=1009 terminate called after throwing an instance of 'char const*' maildrop: signal 0x06 I did some more testing, It appears to be working if I set it gid, with permitions 2755. Maildrop is by default member of the mail group and owned by user root.
Well, it seems there is no other way, postfix does not set group id when it executes maildrop, so either it has to be gid, or courier-imap has to allow auth from user vmail. For now I'll keep maildrop to 2755
http://dev.gentoo.org/~ferdy/overlay/mail-filter/maildrop/maildrop-1.8.0-r1.ebuild That ebuild should do it as it sets 2755 on /usr/bin/maildrop. Scott, do you know a better solution ? Cheers, Ferdy
1.8.0-r1 did not work for me: dedi courier-imap # maildrop -d yd@troyer.co.at ERR: authdaemon: s_connect() failed: Connection refused Invalid user specified. I already had courier-imap-3.0.8 wich brings an authdaemon with it -- Now I get this during each env-update: >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... * Cannot add provide 'authdaemond', as a service with the same name exists! strace shows this when executing maildrop: connect(3, {sa_family=AF_FILE, path="/var/lib/courier/authdaemon/socket"}, 110) = -1 ECONNREFUSED (Connection refused) and the socket is in /var/lib/courier-imap/authdaemon/socket (this happens on amd64 if that makes a differenece). What a mess -- help, somebody :-\
Forgotten: 'Connections refused' was originally 'No such file or directory' - ERR: authdaemon: s_connect() failed: No such file or directory Invalid user specified. (I tried to link to /var/lib/courier-imap/authdaemond/sock when it became 'connection refused'.)
Could you post the USE flags you used to build maildrop and courier-imap ? Is your maildrop executable setgid mail ? Cheers, Ferdy
Since maildrop(1) says: "It is safe to install maildrop as a root setuid program.". Thats what I did so no one will have problems with it. maildrop-1.8.0-r2 is on CVS give it a while to appear on the rsync mirrors. Reopen if it doesn't fix for you (though it should :P) Regards, Ferdy