4 messages in net.sourceforge.lists.courier-maildropRE: [maildropl] Re: maildrop/mysql, s...
FromSent OnAttachments
Joris makMay 21, 2004 4:19 pm 
Joris makMay 22, 2004 4:39 am 
Tony EarnshawMay 22, 2004 7:57 am 
Matthew R J AndersonMay 27, 2004 8:57 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:RE: [maildropl] Re: maildrop/mysql, signal 0x0B (only with postfix)Actions...
From:Matthew R J Anderson (sp@iddx.net)
Date:May 27, 2004 8:57:39 am
List:net.sourceforge.lists.courier-maildrop

I went on a limb when I set maildrop+mysql to work and in my maildropmysql.config, I statically set the uid/gid lookup fields to look like this:

uidnumber_field "524" gidnumber_field "524"

...which is the uid/gid of my vmail user. I'm not sure if this is documented, but it functions properly!

It doesn't make sense to me to have different users in a virtual mail system. My idea was to not have system accounts for e-mail users. I suppose I could understand if there were multiple e-mail 'organizations,' or something, but it simply really doesn't make sense to me. I don't even have a MySQL field for my mailbox's uid/gid, it's pointless.

Hoping this helps some..

/m

-----Original Message----- From: cour@lists.sourceforge.net [mailto:courier- mail@lists.sourceforge.net] On Behalf Of Joris mak Sent: Saturday, May 22, 2004 6:39 AM To: cour@lists.sourceforge.net Subject: [maildropl] Re: maildrop/mysql, signal 0x0B (only with postfix)

Replying to my own post, nice :). But I fixed my problem, so I wanted to give the solution.

Someone sent an email to me about some code fixes, but my problem was that it only gave 0x0b from the postfix setup, not from the command line. I looked at the maildrop binary, and it was owned by the uid/gid of my 'vmail' user (owner of the mailboxes, and the user that postfix runs maildrop as). I remembered reading about maildrop and setsuid, and also from the man page that maildrop tries to change the uid of the process to the user it looks up from the db.

Sooo... changed the owner of the maildrop binary to root, and set the +s flag. Everything works fine now.

But setting setsuid, is that the correct thing todo?

Hey there,

First of all, sorry for a post about this topic, because I have the feeling the answer is around somewhere already, but I just can't seem to find it.

I'm trying to go to the widely used postfix/mysql/amavis/spamass/maildrop combo, and using virtual mailboxes.

The problem is with maildrop at this moment. My gentoo system normally installs 1.5.3, neatly with MySQL support. But I was getting 0x0B whatever I tried. I compiled 1.6.3 from source (regular configure/make/make install) and still got 0x0B problems.

Finally after trying to compile with the -g flag to get debugging, and running maildrop through gdb, I found that the problem was with the contents of my mysql 'quota' field. It was a NULL value, and maildrop tries to strdup() on that NULL value. -> SIGSEGV. Anyways, just putting an empty string into the quota field fixed that.

Now, if I cat a test message to maildrop (cat testmessage | maildrop -d "testuser@testdomain") it works fine. The message neatly flows through spamc and makes it into the correct folder.

When I try it with the MTA system (that means, I sent a test message to my postfix installation, either with a real mail client or with a telnet session) maildrop again sigsegv's with 'signal 0x0b' and the message is set in the deferred state in the postfix queue.

In my MySQL logs I see that maildrop executes a query. If I copy&paste that query into a mys ql prompt, it returns nicely.

---------------entry from postfix' master.cf ----------------- maildrop unix - n n - - pipe flags=R user=vmail argv=/usr/bin/maildrop -d ${recipient}

--------------------------------------------------------------------

I tried running ./configure with CFLAGS= and CXXFLAGS= to disable all those gentoo optimizations.. still no luck. I'm testing it on a Pentium 3-M.

Also with a maildorprc that contains nothing more than a: to "$HOME/$DEFAULT" I still get 0x0b. (If I run maildrop from the commandline $HOME/$DEFAULT expands nicely to the target mailbox, I checked with the log/logfile statements from maildrop).

Is there any bug or patch I'm missing? I'm I simply doing something wrong? Who can help :). If you need extra information, please don't hesitate to ask.

- Joris Mak