[ mailman-Bugs-863989 ] Postfix delayed notification not recognized.

SourceForge.net noreply at sourceforge.net
Tue Mar 7 00:46:47 CET 2006

Bugs item #863989, was opened at 2003-12-21 07:49
Message generated for change (Comment added) made by msapiro
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: bounce detection
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Andree (m-a)
Assigned to: Nobody/Anonymous (nobody)
Summary: Postfix delayed notification not recognized.

Initial Comment:

I am running Mailman 2.1.3 (stable) with Postfix 2.0.16-20031022. 
It seems to be running fine with the VERP patch (it is comfortably 
surprising to see how much Mailman has matured since the 
unusable 1.1 version - I hated 1.1 but I do like 2.1! You've done 
wonderful work.)

However I have one problem that I cannot resolve myself:

Mailman apparently does not parse Postfix' delayed notification 
which is apparently RFC-1894 conformant (Postfix hasn't been 
updated to RFC-3464 yet).

On superficial inspection, it looks as though Mailman's 
Bouncers/DSN.py should handle it and return "Stop", as but I'm 
getting this "uncaught bounce" message which I interpret as 
"haven't figured anything reasonable from this bounce".

The unintelligible bounce is attached and has had mail addresses 
changed (sed) and the delayed mail header removed for privacy 
reasons. I can provide the full message to a developer on request, 
but I cat not put it into a public bug tracker.

The MIME structure of Postfix' delay notification is:

1 multipart/report
1.1 text/plain
1.2 message/delivery-status
1.3 text/rfc822-headers

The message/delivery-status part has "Action: delayed" in the 2nd 
header block. See for yourself.

Am I misunderstanding Mailman
or is Mailman misunderstanding Postfix?

Thanks in advance.


>Comment By: Mark Sapiro (msapiro)
Date: 2006-03-06 15:46

Logged In: YES 

m-a's comments from 2003-12-28 are correct. The 'Stop'
signal was not being passed from BouncerAPI to the
BounceRunner. This has been fixed in CVS and will be correct
in Mailman 2.1.8.


Comment By: Matthias Andree (m-a)
Date: 2003-12-28 19:40

Logged In: YES 

Urgh. Did I say I have these narrow edit forms and line
breaking behind my back without preview? Please apologize
the awful formatting.


Comment By: Matthias Andree (m-a)
Date: 2003-12-28 19:38

Logged In: YES 

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
"bounce recognized, no addresses" and "bounce unrecognized",
back to its

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

What do you think?


Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-26 22:50

Logged In: YES 

Hmm, I get Stop when I run this message through the DSN.py
bounce processor, so as near as I can tell, this is working


You can respond by visiting: 

More information about the Mailman-coders mailing list