[ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce
SourceForge.net
noreply at sourceforge.net
Tue Mar 7 15:32:10 CET 2006
Bugs item #1421285, was opened at 2006-02-01 10:24
Message generated for change (Comment added) made by m-a
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_id=103
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: Open
Resolution: None
Priority: 5
Submitted By: Matthias Andree (m-a)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1.7 (VERP) mistakes delay notice for bounce
Initial Comment:
Greetings,
I just got the bounce action notice specified below.
I am running Mailman 2.1.7 with SF Patch #1405790 on
Python 2.3.4, SUSE Linux 9.2 i586, Postfix 2.2.9.
It appears as though Mailman 2.1.7 were not properly
detecting this apparently RFC-1894 compliant notice as
a "delayed" notice which is definitely a "soft bounce",
if it is supposed to contribute to the bounce score at
all.
I looked at Mailman 2.1.4 or so which appeared to make
efforts to not count "delayed"/deferral notices at all,
but that didn't work at the time for Postfix deferral
notices and was IIRC fixed later.
My setup is VERP enabled, uses VERP for almost
everything and uses monthly reminders for this list.
Jan 27 20:33:47 2006 (6794) leafnode-list:
admin at example.com has stale bounce info, resetting
Jan 27 21:57:08 2006 (6794) leafnode-list:
admin at example.com already scored a bounce for date
27-Jan-2006
Jan 30 18:16:47 2006 (6794) leafnode-list:
admin at example.com current bounce score: 2.0
Jan 30 19:40:06 2006 (6794) leafnode-list:
admin at example.com already scored a bounce for date
30-Jan-2006
Feb 01 03:01:40 2006 (6794) leafnode-list:
admin at example.com current bounce score: 3.0
Feb 01 03:01:41 2006 (6794) leafnode-list:
admin at example.com disabling due to bounce score 3.0 >= 3.0
Feb 01 03:31:41 2006 (6794) leafnode-list:
admin at example.com residual bounce received
I masked the list host by ... and the subscriber's
domain by example.com and the last two components of
the IPv4 address by X, without loss of accuracy I hope,
to protect the site from spammers.
Can anyone shed any light why Mailman 2.1.7 with said
patch considers the delay notice a "hard" bounce?
I don't have time to do debugging right now (end of the
month might work), but applying a patch will probably work.
-----------
This is a Mailman mailing list bounce action notice:
List: leafnode-list
Member: admin at example.com
Action: Subscription deaktiviert.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman at ...
From: MAILER-DAEMON at ... (Mail Delivery System)
Subject: Delayed Mail (still being retried)
To: leafnode-list-bounces+admin=example.com at ...
Date: Wed, 1 Feb 2006 02:47:07 +0100 (CET)
This is the Postfix program at host ...
####################################################################
# THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND
YOUR MESSAGE. #
####################################################################
Your message could not be delivered for 4.2 hours.
It will be retried until it is 7.0 days old.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The Postfix program
<admin at example.com>: connect to
mail.example.com[60.234.X.X]:
Connection timed out
Reporting-MTA: dns; ...
X-Postfix-Queue-ID: C9BC24415A
X-Postfix-Sender: rfc822;
leafnode-list-bounces+admin=example.com at ...
Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET)
Final-Recipient: rfc822; admin at example.com
Action: delayed
Status: 4.0.0
Diagnostic-Code: X-Postfix; connect to
mail.example.com[60.234.X.X]:
Connection timed out
Will-Retry-Until: Tue, 7 Feb 2006 21:55:44 +0100 (CET)
[5. Undelivered Message Headers --- text/rfc822-headers]
(elided)
-------------------------
I pasted from Emacs/Gnus, and this is the mime
structure as seen by Gnus, it looks intact.
. 20060201T030141 [ 150: mailman at dt.e-tec] <* mixed>
Bounce-Benachrichtigung
. 20060201T030141 [ 14: mailman at dt.e-tec] <1 text>
. 20060201T030141 [ 125: mailman at dt.e-tec] <2 rfc822>
. 20060201T024707 [ 111: Mail Delivery Sy] <2.*
report> Delayed Mail (still being retried)
. 20060201T024707 [ 19: Mail Delivery Sy] <2.1
text>
. 20060201T024707 [ 13: Mail Delivery Sy] <2.2
delivery-status>
. 20060201T024707 [ 63: Mail Delivery Sy] <2.3
rfc822-headers>
----------------------------------------------------------------------
>Comment By: Matthias Andree (m-a)
Date: 2006-03-07 15:32
Message:
Logged In: YES
user_id=2788
The Postfix maintainer's opinion is to continue ignoring the
Precedence: header. He writes that Mailman should heed
RFC-1894 info. See
http://marc.theaimsgroup.com/?l=postfix-users&m=114173451818447&w=1
----------------------------------------------------------------------
Comment By: Matthias Andree (m-a)
Date: 2006-03-07 09:19
Message:
Logged In: YES
user_id=2788
An MTA ignoring Precedence: headers is certainly NOT
misconfigured. According to RFC-2076 and 3834, this header
is non-standard, controversial, its interpretation varies
and its use is not encouraged.
I doubt Postfix implementors would care about such a
non-standard header, and shifting the responsibility for not
taking action in response to properly-formatted RFC-1894
DSNs towards MTA authors doesn't positively scale...
BTW, is this related to Bug #863989?
The message received at the VERP bounce address could be put
through the bounce parser the same way as bounces to the
generic bounce address to obtain one of three results: 1. an
address, 2. a reply "unparsable", 3. a reply "stop". The
former two would be subjected to bounce processing, where in
case (1) the VERP address would override the address
extracted from the message, case (3) last would just discard
the message.
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-03-04 15:41
Message:
Logged In: YES
user_id=12800
In general, an MTA is misconfigured if it sends a warning to
a message labeled Precedence:bulk and all Mailman mailing
list copies are so labeled.
----------------------------------------------------------------------
Comment By: Matthias Andree (m-a)
Date: 2006-03-04 10:54
Message:
Logged In: YES
user_id=2788
VERP doesn't indicate the bounce status of a message, it is
a tool EXCLUSIVELY to determine the actual subscriber
address in the face of forwards, DNS aliases and everything,
to make sure that the list driver knows which subscriber to
attribute the bounce to.
Assuming any message sent to an address that looks like VERP
were a bounce is a security risk!
The message I'd reported was well-formed RFC-1894 and so the
parser would not have had any difficulties finding out it
should ignore the message.
I am aware that this isn't bullet-proof, that's why I
suggested sending a probe message with secret hash before
disabling/unsubscribing a user a long time ago.
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2006-03-04 08:37
Message:
Logged In: YES
user_id=1123998
Unfortunately, this is the way VERP bounce processing is
handled. When a message is sent/returned to
listname-bounces+user=example.com at ... it is scored as a
bounce for user at example.com (the VERPed address), and the
content of the message is never examined.
The theory is that the VERP address identifies the bouncing
address regardles of the recognizability of the notice
itself, so there is no attempt to recognize the type of notice.
It would be possible to run the returned message through the
recognizers and accept a recognizers determination that the
notice was non-fatal while still keeping the VERP address as
the address to use for the bounce report in the event that
the notice was not determined to be non-fatal, but that
wouldn't solve the problem for an unrecognized non-fatal
notice, and the whole idea behind VERP bounce processing is
that it allows skiping the recognition process.
It does seem wrong that a bounce is scored for a notice that
could be recognized as non-fatal, but there will always be a
grey area with notices that wouldn't be recognized as fatal
or non-fatal. If one decides to give the benefit of the
doubt in this grey area and not score a bounce, then we
revert to the non-VERP case in which only recognized bounces
are scored.
It seems that the real problem is that VERP bounce
processing isn't that good of an idea.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_id=103
More information about the Mailman-coders
mailing list