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