upgrade probs, w/sendmail 8.11.6 non-milter

Help
2004-11-11
2013-04-11
  • The Mindflayer
    The Mindflayer
    2004-11-11

    I'm sorry to bother you all with this, but as you'll see, I've exhausted just about every other option.

    I have a working setup with amavisd-new-20030616 and sendmail 8.11.6 (with backported patches) non-milter to scan all relayed and local mail.  Yes, it's very deprecated/obsolete, but it's the only setup our server can handle at the moment -- and it works.  (Trust me, I'd be the happiest person in the world if an MTA upgrade were possible.)

    In order to support SpamAssassin 3, and just in the interests of having updated software, I'm trying to upgrade to amavisd-new-2.2.0, and I'm having all kinds of trouble.

    1. CURRENT SETUP AND UPGRADE PREPARATIONS

    The sendmail daemon (using config sendmail.cf) passes the mail to the helper program /usr/sbin/amavis, which passes the mail to amavisd, which then forwards/delivers using another sendmail instance (using config sendmail.orig.cf).  Everything works just fine.

    Config file:  As recommended way back when on the amavis users list for upgrades, I diffed the 20030616 production config file against the default 20030616 config file to get the changes I made, and applied them by hand against the default 2.2.0 config file.  I had to make some adjustments for the change in the local domain lookup handling.  I also tweaked a few more options that just made sense.  No problems there as far as I can tell.

    I also had to apply a trivial fix I had to write for amavisd-new-20030616.  It makes amavisd give SMTP response "250 2.6.0 Ok" instead of "550 5.1.1 Recipient unknown" on EX_NOUSER, because otherwise there would be double bounces.  (Sendmail with sendmail.orig.cf already sent a bounce message, so sendmail with sendmail.cf needs to think the message was sent successfully.)  No biggie.  Speaking of double bounces, I think I saw a query about that on this list from a person with a similar setup as mine, with 0 replies.  Perhaps you can add a setting to amavisd to prevent the double bounces when using amavisd with this obsolete setup, or at least add a note to the sendmail README.

    Here's the current setup:

    amavisd.conf:
    $forward_method = 'pipe:flags=q argv=/usr/sbin/sendmail -C/etc/sendmail.orig.cf -i -f ${sender} -- ${recipient}';
    $notify_method = $forward_method;

    Mamavis,        P=/usr/sbin/amavis, F=mlsACDFMS5:/|@qhP, S=0, R=0,
                    T=DNS/RFC822/X-Unix, U=root:amavis,
                    A=amavis $f $u

    For the new version, the docs say to use the "n" flag for the amavis helper, so I added it:

    Mamavis,        P=/usr/sbin/amavis, F=nmlsACDFMS5:/|@qhP, S=0, R=0,
                    T=DNS/RFC822/X-Unix, U=root:amavis,
                    A=amavis $f $u

    2. THE PROBLEM

    When I put all the files in place and restart amavisd and sendmail, I'm greeted with all kinds of problems.  (I'm glad I had the foresight to write a revert script.  Whew.)  This gets put into the mail log:

    Nov 11 09:39:40 CENSORED sendmail[16606]: iABEdaK16553: to=<CENSORED@CENSORED.com>, delay=00:00:02, xdelay=00:00:01, mailer=amavis, pri=34864, dsn=5.3.0, stat=unknown mailer error 99

    So obviously /usr/sbin/amavis is returning 99 to sendmail.  I traced through the amavis helper C code.  Right near the end, you see that if amavis receives a 99 return status from amavisd when called with no lda arguments, it just exits with 99 back to sendmail.  Last I saw, 99 is NOT a valid exit status for a mailer.  I don't blame sendmail for getting confused.  At least it's an obvious problem.  It's better than failing silently.

    Obviously, the 99 exit status is a symptom of something worse.

    I looked at the amavisd log on level 5 (most verbose).  Errors that I'm getting are:

    Nov 11 09:39:40 CENSORED /usr/local/sbin/amavisd[16603]: (16603) BAD HEADER from <CENSORED@CENSORED.com>: Invalid header field head: From CENSORED@CENSORED...

    and

    Nov 11 09:39:40 CENSORED /usr/local/sbin/amavisd[16603]: (16603) WARN: no recips left (forgot to set $forward_method=undef using milter?), 250 2.7.1 Ok, discarded, UBE, id=16603
    Nov 11 09:39:40 CENSORED /usr/local/sbin/amavisd[16603]: (16603) mail checking ended: setreply=250 2.7.1 Ok,%20discarded,%20UBE,%20id=16603\nreturn_value=discard\nexit_code=99

    Looking at the amavisd code, I see what when amavisd runs out of recips, it sends back a return code of 99 ("discard") to the amavis helper program, which the amavis helper program returns to sendmail.

    It looks like I have 2 problems:

    1) bad header complaint.
    2) amavisd somehow doesn't see the recipient(s), or it doesn't handle them properly

    These two could be related -- "From " header problem and amavis not seeing recipients.

    For the Bad header complaint, I thought the "n" flag in the sendmail mailer definition was supposed to stop the "From " header from being passed to the mailer.  At least, that's what it seems to say in my copy of the bat book (3rd edition), section 2.8.36 (at the end of the "Delivery Agent F= flags" section).  Hmm.

    I know amavisd sees the recipients, as lines like this are in the logs, too:

    Nov 11 09:39:39 CENSORED /usr/local/sbin/amavisd[16603]: (16603) lookup (blacklist_recip<CENSORED@CENSORED.com>) => undef, "CENSORED@CENSORED.com" does not match

    Nov 11 09:39:39 CENSORED /usr/local/sbin/amavisd[16603]: (16603) lookup (whitelist_recip<CENSORED@CENSORED.com>) => undef, "CENSORED@CENSORED.com" does not match

    Nov 11 09:39:42 CENSORED /usr/local/sbin/amavisd[16604]: (16604) headers CLUSTERING: done all 1 recips in one go

    So, any ideas?  Thanks.

    The Mindflayer