Comment 2 for bug 266003

Hum, looks like this issue isn't Postfix specific, but
affects all
systems that send a delay notification.

"logs/bounce" contains:
Dec 27 20:35:45 2003 (2053) bounce message w/no discernable
addresses: <mumble>
Dec 27 20:35:45 2003 (2053) forwarding unrecognized,
message-id: <mumble>

If I save exactly this mail (I checked the Message-ID) and
feed it to
onebounce.py, I'm getting "DSN got Stop", so that part is fine.

I've dug a bit deeper, and noticed a difference between
onebounce.py and
BouncerAPI.ScanMessages. See lines 65ff in BouncerAPI.py:

        addrs = sys.modules[modname].process(msg)
        if addrs is Stop:
            # One of the detectors recognized the bounce,
but there were no
            # addresses to extract. Return the empty list.
            return []

I wonder if ScanMessages() is doing the right thing, mapping
Stop to [].
Evidently, the BounceRunner assumes [] is a parse failure
(no addresses
returned) and ultimately forwards the "delay notification"
to the admin
contrary to original DSN.py "Stop" intent. To me, it seems
as though
ScanMessages needed a fix that allows it to propagate both
states,
"bounce recognized, no addresses" and "bounce
unrecognized",
back to its
caller.

I wonder if the "Stop" condition should be exposed to the
BounceRunner
or some other interface extension in ScanMessages.

What do you think?