Re: Wrong address unsubscribed

>   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