Maildrop gives signal 0x0B (that's SEGV right?) SOLVED

[Kailee]

Hi all,

I have a perfectly working postfix+mysql+courier-imap setup with two virtual domains. I would like to add maildrop to add mail filtering, but am having no luck.
I'm running:

Code: Select all

postfix-2.0.19
mysql-4.0.18-r2
courier-imap-3.0.2
maildrop-1.5.3-r1
spamassassin-2.63

Here is my /etc/maildroprc (leaving out postfix, courier-imap and mysql configs as they are not yet involved and work fine anyway):

Code: Select all

DEFAULT="${HOME}/Maildir/"
xfilter "/usr/bin/spamc"
if (/^X-Spam-Flag: YES/)
{
to $DEFAULT/.Spam/
}

My mysql.log tells me that the queries work fine:

Code: Select all

Tcp port: 3306  Unix socket: /var/run/mysqld/mysqld.sock
Time                 Id Command    Argument
040625 15:07:47       1 Connect     mailsys@localhost on
                      1 Init DB     maildb
                      1 Query       SELECT id, uid, gid, home, maildir, quota, smtpok FROM users WHERE id = "user@domain.com"
                      1 Quit

Running maildrop manually gets me this (adresses edited):

Code: Select all

thorin root # cat spamtxt | maildrop -d user@domain.com -V 5
maildrop: Changing to /var/export/home/domain.com/user
Message start at 0 bytes, envelope sender=user@domain.com
/etc/maildroprc(2): DEFAULT="/var/export/home/domain.com/user/Maildir/"
/etc/maildroprc(3): LOGDIR="/var/log"
/etc/maildroprc(5): Opening logfile /var/log/maildrop.log
maildrop: Filtering through xfilter /usr/bin/spamc
/etc/maildroprc(8): Evaluating IF condition.
Matching /^X-Spam-Flag: YES/ against Received: from localhost by mail.domain.com with SpamAssassin (2.63 2004-01-11);    Fri, 25 Jun 2004 15:36:35 +0200
Not matched.
Matching /^X-Spam-Flag: YES/ against From: Sender <sender@example.net>
Not matched.
Matching /^X-Spam-Flag: YES/ against To: Recipient <user@domain.com>
Not matched.
Matching /^X-Spam-Flag: YES/ against Subject: Test spam mail (GTUBE)
Not matched.
Matching /^X-Spam-Flag: YES/ against Date: Fri, 25 Jun 2004 11:00:00 +0200
Not matched.
Matching /^X-Spam-Flag: YES/ against Message-Id: <GTUBE1.1010101@example.net>
Not matched.
Matching /^X-Spam-Flag: YES/ against X-Spam-Flag: YES
/etc/maildroprc(8): Search of ^X-Spam-Flag: YES = 1
/etc/maildroprc(8): IF evaluated, result=1
maildrop: Attempting .mailfilter
maildrop: Delivery complete.
maildrop: signal 0x0B

Note the maildrop: signal 0x0B (aka 11!). Changing the "to" line in maildroprc makes no difference (i.e. "to $DEFAULT" for instance), except when I take it out entirely, but leaving the regex pattern; then mail gets filtered and delivered with no errors (plus it shows that the pattern matching is not the culprit):

Code: Select all

maildrop: Changing to /var/export/home/domain.com/user
Message start at 0 bytes, envelope sender=user@domain.com
/etc/maildroprc(2): DEFAULT="/var/export/home/domain.com/user/Maildir/"
/etc/maildroprc(3): LOGDIR="/var/log"
/etc/maildroprc(5): Opening logfile /var/log/maildrop.log
maildrop: Filtering through xfilter /usr/bin/spamc
/etc/maildroprc(8): Evaluating IF condition.
Matching /^X-Spam-Flag: YES/ against Received: from localhost by mail.domain.com with SpamAssassin (2.63 2004-01-11);    Fri, 25 Jun 2004 15:36:35 +0200
Not matched.
Matching /^X-Spam-Flag: YES/ against From: Sender <sender@example.net>
Not matched.
Matching /^X-Spam-Flag: YES/ against To: Recipient <user@domain.com>
Not matched.
Matching /^X-Spam-Flag: YES/ against Subject: Test spam mail (GTUBE)
Not matched.
Matching /^X-Spam-Flag: YES/ against Date: Fri, 25 Jun 2004 11:00:00 +0200
Not matched.
Matching /^X-Spam-Flag: YES/ against Message-Id: <GTUBE1.1010101@example.net>
Not matched.
Matching /^X-Spam-Flag: YES/ against X-Spam-Flag: YES
/etc/maildroprc(8): Search of ^X-Spam-Flag: YES = 1
/etc/maildroprc(8): IF evaluated, result=1
maildrop: Attempting .mailfilter
maildrop: Delivery complete.

The signal 0x0B means postfix won't complete the delivery, re-queueing the message (even though it's already got to the correct mailbox), and will then just go through the loop again and again.

I googled for the 0x0B in connection to maildrop and found some references to people re-emerging with CFLAGS and CXXFLAGS empty, so I tried this also but it didn't change anything. So long as I don't want to re-direct spam-flagged email all is well, but the point behind maildrop for me is not just running the xfilter but also delivering to a different maildir...

There were other suggestions on the net to adjust suid and permissions on /usr/bin/maildrop but this made no difference either.

Does anyone have any idea of what might be wrong?

Kailee.

PS: Could this be perl related?

[jkt]

0x0b==11(dec)==SIGSEGV (`man 7 signal`)

[Kailee]

I found the culprit; there is a --enable-syslog configure option to maildrop that is enabled in the ebuild by default. So I guess what is happening is that maildrop (when used with -d) changes it's uid to the effective user, who is then (usually) not allowed to write to the syslog - which is what it tries to do after every successful delivery. And so it SIGSEGV's.
Setting --enable-syslog=0 in the .ebuild solves this problem.

Which gets me to my next question; is there a way for me to set this option somewhere in a file so that when a new ebuild is published through portage that I won't have to edit the ebuild everytime? Or would this actually be enough of a bug that it should be filed under bugs.gentoo.org?

Noone else seems to have complained about this so I'm really wondering how those other people get around this problem!

Thanks for any info,


Kailee.

[jkt]

AFAIK any process is able to write into syslog. your problem might be some insane optimizations. what are your CFLAGS?

[fls]

I just encountered the exact same symptom (signal 0x0b), but neither syslog nor unsane CFLAGS where the problem.
In fact, maildrop wasn´t able to read /etc/maildrop/maildropmysql.cf because I messed up with permissions.
After giving my virtual mail user read permissions on the file all is well again.

Maybe this post can save s.o. some troubleshooting

[jkt]

I just encountered the exact same symptom (signal 0x0b), but neither syslog nor unsane CFLAGS where the problem.
In fact, maildrop wasn´t able to read /etc/maildrop/maildropmysql.cf because I messed up with permissions.

hmm, seems like a bug in maildrop's code/design. is it correct behaviour to die on segfault if the file is missing? imho there's missing some error checking in maildrop's code... submitting bug (with some backtrace if possible ) should be good idea...

[fls]

submitting bug (with some backtrace if possible ) should be good idea...

Yeah, you are right. I was thinking the same and looked for a bugtracker but didn´t found one. Then I had a look at their mailing list, and there is already a thread describing the signal 0x0b problem due to a missing config file.
What would you do? Post it again there... ? Useless I think, because nobody replied to the old thread.
Any advice?

[jkt]

hmm. you have two options:
a) reply to it and ask if it's correct behaviour not to check fopen() or open() calls . but be polite
b) submit bug at bugs.gentoo.org, mention the original thread at sf.net

IMHO it should be fixed, but it's quite a low priority bug.

[fls]

Okay, I decided for a) and sent a polite question to their ML. But the ML is moderated and my mail never got through, although I didn´t get a rejection
But there is bug in gentoos bugzilla and they pushed out a new revision of maildrop's ebuild with the fix included

[Qubax]

Setting --enable-syslog=0 in the .ebuild solves this problem.

this solved the problem for me, too.

[pajai]

Setting --enable-syslog=0 in the .ebuild solves this problem.

this solved the problem for me, too.

Is it normal that this syslog bug is still present in the last ebuild, for maildrop 1.8.0-r3?

Regards,

xrb

EDIT: Ok, it seems the bug is not only due to that syslog issue, as I get the same error without that option. I switched back to maildrop-1.7.0.20040907-r1 and that works. Strange anyway.