I have also seen this problem, and I've reported this to this email list and have never received any response. The problematic site was running iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002) and from bounced emails smartlist extracted I think just the first from in the body it found.

I also ran into this problem some time ago and took a quick look at the procbounce script to see if there was something simple I could fix. At the time, I took the lazy way out and just disabled automatic unsubscription (by setting minbounce higher than maxhist). My problem turned out to be brain-dead vacation replies that got sent back to the main list, diverted to the request list, and contained the email address of someone else to contact in their absence (who, of course, was also on the list)! This discussion motivated me to go back and spend a little more time looking at procbounce. It's actually not as complicated as it looks. It makes four successive attempts to find the offending addresses, each attempt a little bit looser and less reliable than the previous. (I'm still using a fairly old version of procmail/SmartList -- 3.13 -- so some of this might look different in the latest versions.) The first three attempts are made on a filtered version of the bounce message -- a formail/sed pipe that removes lines that are certain not to contain the offending address, or that are likely to contain other addresses that should *not* be removed. The first attempt uses a rule that looks for lines that begin with a "5xx" sendmail error: addr=`sed -n -e '/^5[0-9][0-9] /p' <$tmpfrom | $multigram -b1 -l$off_threshold -x$listaddr -x$listreq $dist` If this doesn't find anything, the second attempt looks for an email address anywhere in the filtered message (the default value of "$off_threshold" is 24476): test -z "$addr" && addr=`$multigram -b1 -l$off_threshold -x$listaddr -x$listreq $dist <$tmpfrom` The third attempt is even looser (-i allows matching incomplete addresses, and the match threshold is even lower): test -z "$addr" && addr=`$multigram -i -b1 -l16384 -x$domain $dist <$tmpfrom` Finally, the fourth attempt tries to find the original message that bounced (usually quoted at the end of the returned mail, and looks in the first "Received:" header of that message: $test -z "$addr" && addr=`$formail -1 +1 -dem4 -XReceived: -uReceived: <$tmprequest -s | $multigram -i -b1 -l16384 -x$domain $dist ` The first thing I'd suggest trying is to edit your rc.custom file and set off_threshold to "$match_threshold". This will at least make sure that multigram does a strict match against your dist file. Second, I suggest disabling the 2nd, 3rd, and 4th rules in procbounce -- just comment these lines out: # test -z "$addr" && # addr=`$multigram -b1 -l$off_threshold -x$listaddr -x$listreq $dist <$tmpfrom` # test -z "$addr" && # addr=`$multigram -i -b1 -l16384 -x$domain $dist <$tmpfrom` # $test -z "$addr" && # addr=`$formail -1 +1 -dem4 -XReceived: -uReceived: <$tmprequest -s | # $multigram -i -b1 -l16384 -x$domain $dist ` Then you can take a closer look at the bounces that get through. That might suggest a way to loosen up the first rule (perhaps those "5xx" lines have some prefix in front of them), tighten up the second rule, or fiddle with the filter that creates the tmp.from file. In looking through my log of bounce messages from a variety of servers, it looks like nearly all of them would match on the first rule, so I think you'd end up having very few bounces to process manually by simply leaving the other three rules commented out. In the scenario that started this thread (A rejecting mail from B), it's clear that the second rule is matching B's address because it was listed in full, while A's address was listed without the "@aol.com". By disabling the second rule, these messages will simply be ignored and won't cause any bounce processing. Alternatively, you could edit the filters (add another sed expression, like "/not accepting mail from/d") to make sure that the line containing B's address is filtered out so that the tests never see that address. Then the third rule might actually match A's address even without the domain. Good luck! -cary

I've recently had several regular messages bounced with X-Diagnostic: already on the subscriber list even though the messages contain nothing even remotely resembling "subscribe". Logs show that for some reason they are interpreted as administratice commands by rc.submit, sent on to rc.request which apparently treats as subscription requests everything that doesn't look like anything it knows. What the offensive messages have in common is that they are short and begin with a number or with a non-ASCII letter. The regexps in rc.submit are a bit convoluted, but if I read them right, any message shorter than 640 characters and 6 lines that doesn't begin with a letter (after indentation, if any) is passed to rc.request. I guess such messages are quite rare in English, but in Finnish they're much more common (both because several Finnish letters are not included in [a-z] but also because sentences beginning with numbers are common for grammatical reasons). If I understand correctly, the key regexp is this: * -100^0 B ?? ^^([ ]|$)*\ ((((archives?:?($|[ ]+)|\ ((send|get)(me)?|gimme|retrieve|mail|ls|dir(ectory)?|\ list|show|search|[fe]?grep|find|maxfiles|version|help|info)\ ([ ].*)?$)([ ]|$)*)+\ ([^ a-z].*$(.*$(.*$(.*$(.*$)?)?)?)?)?^^|\ (help|info)[ ]*$|\ (add|join|leave|sign( [^ ]+ |-)?o(n|ff)|(un|de)?-?sub)\>)|\ ([^ a-z].*$(.*$(.*$(.*$(.*$)?)?)?)?)?^^|\ .*( (join|leave|add .* to|(delete|remove) .* from|\ (take|sign|get) .* off|(put|sign) .* on) .* [a-z-]*list|\ (un-?|sub?)scri(be|ption))\>|\ ^^) and in particular line ([^ a-z].*$(.*$(.*$(.*$(.*$)?)?)?)?)?^^|\ which, in conjunction with the first line there matches if the message begins with anything other than a letter a-z or whitespace (or is empty) and is at most six lines long. Am I reading this right? Why are such messages being trapped - I thought request messages usually begin with letters? Or, what exactly is that trying to catch, how much do I dare to modify it without breaking something? If I remove that one line entirely, what will break? -- Tapani Tarvainen