Bugs item #1433666, was opened at 2006-02-17 08:02
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433666&group_…
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: nntp/news
Group: 2.1 (stable)
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Dâniel Fraga (danielfraga)
Assigned to: Nobody/Anonymous (nobody)
Summary: News to mail gateway: Outlook Express broke uuenc.attachment
Initial Comment:
When someone posts on my nntp server a message with an
uuencoded attachment using Outlook Express, the message
appears broken in mailman.
For example:
Original message:
news://news.abusar.org/drq50u$gmp$2@servicos.netuno.com.br
Mailman message (corrupted):
http://core.abusar.org/pipermail/u-br.lazer.humor/2006-February/000346.html…
I think the problem is related to how mailman handles
the end of lines...
Thank you.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-03-07 09:45
Message:
Logged In: YES
user_id=1123998
Absent any reply to my previous comment, I'm closing this.
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2006-02-17 17:22
Message:
Logged In: YES
user_id=1123998
Are you talking only of archived messages or individual
received messages as well?
In the case of the archived message you point to, the
problem is that you have configured the archiver to obscure
email addresses so that every '@' character in the uuencoded
data is rewritten as ' em '.
The issue is compounded by Outlook Express, because when
Outlook Express sends a uuencoded attachment, it does not
actually encapsulate the uuencoded attachment in a separate
MIME part. If it did, Scrubber would store it separately and
put a link to it in the archived message, but in the Outlook
Express case, the 'attachment' is not an attachment at all,
but rather just a uuencoded file in the body of the message.
Thus, it is just more text subject to munging by email
address obscuring.
I was going to close this report with the above explanation,
but I am waiting to hear if you also have a problem with
individual messages or digests. I know my explanation is
correct for the archives because I took the uuencoded data
from your archive page and replaced all the ' em ' with '@',
and I was then able to uudecode the file into a valid jpeg.
So, do you have a problem with messages or digests from the
list, and if so, can you provide an example message for
analysis?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433666&group_…
Bugs item #1442639, was opened at 2006-03-03 10:27
Message generated for change (Settings changed) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442639&group_…
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: Pipermail
Group: 2.1 (stable)
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: R. Scott Bailey (rscottbailey)
Assigned to: Nobody/Anonymous (nobody)
Summary: attachments archived even when archiving disabled
Initial Comment:
I just noticed disappearing disk space under /var on
my Debian system running mailman 2.1.7... :-)
Investigation reveals lots of space tied up
under /var/lib/mailman/archives/private/<list>/attachm
ents/<yyyymmdd>/<blah> -- it appears that any message
containing an attachment causes the attachment to be
stashed here in the archive tree, even when archiving
is disabled (and nothing else in the archives tree is
getting updated).
I do not believe it is correct behavior for
attachments to be saved in these circumstances.
Thanks,
Scott Bailey
scott.bailey(a)eds.com
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-03-07 09:43
Message:
Logged In: YES
user_id=1123998
Closing per my previous comment.
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2006-03-03 10:45
Message:
Logged In: YES
user_id=1123998
This is expected behavior. The scrubber saves attachments in
the archives/private/<listname>/attachments/ directory. This
happens for all messages if scrub_nondigest is Yes, and for
all plain digests in any case even if the list does not do
archiving.
If you allow attachments at all, the only way to avoid this
is to set both scrub_nondigest and digestable to No. I.e,
don't scrub individual messages and don't allow digests.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442639&group_…
Bugs item #1442801, was opened at 2006-03-03 15:42
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442801&group_…
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: mail delivery
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Carter (grandcross)
Assigned to: Nobody/Anonymous (nobody)
Summary: ToDigest failing with missing attribute error
Initial Comment:
One of my list queues has stopped sending messages due
to a missing method:
Mar 03 18:11:02 2006 (16865) Uncaught runner exception:
'str' object has no attribute 'get'
Mar 03 18:11:02 2006 (16865) Traceback (most recent
call last):
File "/usr/lib/mailman/Mailman/Queue/Runner.py", line
110, in _oneloop
self._onefile(msg, msgdata)
File "/usr/lib/mailman/Mailman/Queue/Runner.py", line
160, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
File
"/usr/lib/mailman/Mailman/Queue/IncomingRunner.py",
line 130, in _dispose
more = self._dopipeline(mlist, msg, msgdata, pipeline)
File
"/usr/lib/mailman/Mailman/Queue/IncomingRunner.py",
line 153, in _dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py",
line 91, in process
send_digests(mlist, mboxfp)
File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py",
line 132, in send_digests
send_i18n_digests(mlist, mboxfp)
File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py",
line 217, in send_i18n_digests
msgsubj = msg.get('subject', _('(no subject)'))
AttributeError: 'str' object has no attribute 'get'
Mar 03 18:11:02 2006 (16865) SHUNTING:
1141426524.2579081+81281f03f202e0386d5044adcef5083568986f9a
Digest mailbox has now gotten very large (> 4MB) so I
cant attach.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-03-07 09:40
Message:
Logged In: YES
user_id=1123998
Absent any response to the contrary, I'm closing this per my
previous comment - fixed in 2.1.6.
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2006-03-03 16:09
Message:
Logged In: YES
user_id=1123998
This looks like Mailman 2.1.5 or earlier. This problem was
fixed in 2.1.6. At line 210 in your
Mailman/Handlers/ToDigest.py you will see
while msg is not None:
if msg == '':
# It was an unparseable message
msg = mbox.next()
msgcount += 1
You need to add a continue so this becomes
while msg is not None:
if msg == '':
# It was an unparseable message
msg = mbox.next()
continue
msgcount += 1
In the mean time, if you don't mind having your digest out
of sequence, just move the digest.mbox aside. Then you can
patch ToDigest.py and straighten out the digest situation.
Note that you probably don't want to both run bin/unshunt
and replace the digest.mbox as that will result in
duplicates, but if messages haven't reached the list, you
need to run bin/unshunt to finish processing them.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442801&group_…
Bugs item #1421285, was opened at 2006-02-01 01:24
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_…
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(a)example.com has stale bounce info, resetting
Jan 27 21:57:08 2006 (6794) leafnode-list:
admin(a)example.com already scored a bounce for date
27-Jan-2006
Jan 30 18:16:47 2006 (6794) leafnode-list:
admin(a)example.com current bounce score: 2.0
Jan 30 19:40:06 2006 (6794) leafnode-list:
admin(a)example.com already scored a bounce for date
30-Jan-2006
Feb 01 03:01:40 2006 (6794) leafnode-list:
admin(a)example.com current bounce score: 3.0
Feb 01 03:01:41 2006 (6794) leafnode-list:
admin(a)example.com disabling due to bounce score 3.0 >= 3.0
Feb 01 03:31:41 2006 (6794) leafnode-list:
admin(a)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(a)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@...
From: MAILER-DAEMON@... (Mail Delivery System)
Subject: Delayed Mail (still being retried)
To: leafnode-list-bounces+admin=example.com@...
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(a)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@...
Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET)
Final-Recipient: rfc822; admin(a)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(a)dt.e-tec] <* mixed>
Bounce-Benachrichtigung
. 20060201T030141 [ 14: mailman(a)dt.e-tec] <1 text>
. 20060201T030141 [ 125: mailman(a)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: Mark Sapiro (msapiro)
Date: 2006-03-07 08:26
Message:
Logged In: YES
user_id=1123998
It's only distantly related to bug 863989. That that bug has
been fixed in CVS, and in a sense, that fix is prerequisite
to fixing this bug in the way you suggest.
You suggest: "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."
This is very easy to do in code - only a line or two in
BounceRunner now that 863989 is fixed - but the overhead is
possibly significant considering we already have the address.
Also, it is not clear to me whether you would consider your
case (2) to be a bounce for the VERP address. I suggest that
if you do not, the results of the above would rarely be
different from just not doing VERP like addressing in the
first place, thus all I would do differently from current
CVS is discard the message in case (3). Here is how I would
patch the current CVS to do this (note that lines will
probably wrap):
@@ -197,7 +197,11 @@
return
# Try VERP detection first, since it's quick and easy
addrs = verp_bounce(mlist, msg)
- if not addrs:
+ if addrs:
+ # We have an address, but check if the message
is non-fatal.
+ if BouncerAPI.ScanMessages(mlist, msg) is
BouncerAPI.Stop:
+ return
+ else:
# See if this was a probe message.
token = verp_probe(mlist, msg)
if token:
This depends on the fix for bug 863989 which modifies
BounceRunner and BouncerAPI. It would help if you could test
this, although 2.1.8a1 is imminent.
Also, you mention in a comment "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." Isn't that what we currently do if
VERP_PROBES = Yes, and wouldn't that make a disable in this
situation much less likely in the first place?
----------------------------------------------------------------------
Comment By: Matthias Andree (m-a)
Date: 2006-03-07 06: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 00: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 06: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 01: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-03 23: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@... it is scored as a
bounce for user(a)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_…
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_…
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(a)example.com has stale bounce info, resetting
Jan 27 21:57:08 2006 (6794) leafnode-list:
admin(a)example.com already scored a bounce for date
27-Jan-2006
Jan 30 18:16:47 2006 (6794) leafnode-list:
admin(a)example.com current bounce score: 2.0
Jan 30 19:40:06 2006 (6794) leafnode-list:
admin(a)example.com already scored a bounce for date
30-Jan-2006
Feb 01 03:01:40 2006 (6794) leafnode-list:
admin(a)example.com current bounce score: 3.0
Feb 01 03:01:41 2006 (6794) leafnode-list:
admin(a)example.com disabling due to bounce score 3.0 >= 3.0
Feb 01 03:31:41 2006 (6794) leafnode-list:
admin(a)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(a)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@...
From: MAILER-DAEMON@... (Mail Delivery System)
Subject: Delayed Mail (still being retried)
To: leafnode-list-bounces+admin=example.com@...
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(a)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@...
Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET)
Final-Recipient: rfc822; admin(a)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(a)dt.e-tec] <* mixed>
Bounce-Benachrichtigung
. 20060201T030141 [ 14: mailman(a)dt.e-tec] <1 text>
. 20060201T030141 [ 125: mailman(a)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@... it is scored as a
bounce for user(a)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_…
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_…
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(a)example.com has stale bounce info, resetting
Jan 27 21:57:08 2006 (6794) leafnode-list:
admin(a)example.com already scored a bounce for date
27-Jan-2006
Jan 30 18:16:47 2006 (6794) leafnode-list:
admin(a)example.com current bounce score: 2.0
Jan 30 19:40:06 2006 (6794) leafnode-list:
admin(a)example.com already scored a bounce for date
30-Jan-2006
Feb 01 03:01:40 2006 (6794) leafnode-list:
admin(a)example.com current bounce score: 3.0
Feb 01 03:01:41 2006 (6794) leafnode-list:
admin(a)example.com disabling due to bounce score 3.0 >= 3.0
Feb 01 03:31:41 2006 (6794) leafnode-list:
admin(a)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(a)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@...
From: MAILER-DAEMON@... (Mail Delivery System)
Subject: Delayed Mail (still being retried)
To: leafnode-list-bounces+admin=example.com@...
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(a)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@...
Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET)
Final-Recipient: rfc822; admin(a)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(a)dt.e-tec] <* mixed>
Bounce-Benachrichtigung
. 20060201T030141 [ 14: mailman(a)dt.e-tec] <1 text>
. 20060201T030141 [ 125: mailman(a)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 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@... it is scored as a
bounce for user(a)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_…
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:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&group_i…
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:
Hi,
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
Message:
Logged In: YES
user_id=1123998
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
Message:
Logged In: YES
user_id=2788
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
Message:
Logged In: YES
user_id=2788
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?
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-26 22:50
Message:
Logged In: YES
user_id=12800
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
properly.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&group_i…
Bugs item #1444447, was opened at 2006-03-06 13:43
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1444447&group_…
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: command line scripts
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Axel Beckert (xtaran)
Assigned to: Nobody/Anonymous (nobody)
Summary: show_qfiles: 'str' object has no attribute 'as_string'
Initial Comment:
With mailman 2.1.5 and Python 2.4 on SuSE Linux 9.3,
show_qfiles throws an error:
python show_qfiles-2.1.7.orig ~/xchange/test.pck
====================> /home/abe/xchange/test.pck
Traceback (most recent call last):
File "show_qfiles-2.1.7.orig", line 74, in ?
main()
File "show_qfiles-2.1.7.orig", line 67, in main
sys.stdout.write(msg.as_string())
AttributeError: 'str' object has no attribute 'as_string'
Removing the ".as_string()" from the source of
show_qfiles fixes the problem.
show_qfiles is still the same in 2.1.7 and still throws
this error. Tested with 2.1.7 and Python 2.4.1 under
SuSE Linux 10.0.
Patch:
--- show_qfiles-2.1.7.orig 2006-03-06
22:38:46.000000000 +0100
+++ show_qfiles-2.1.7 2006-03-06 22:40:27.000000000 +0100
@@ -64,7 +64,7 @@
fp = open(filename)
if filename.endswith(".pck"):
msg = load(fp)
- sys.stdout.write(msg.as_string())
+ sys.stdout.write(msg)
else:
sys.stdout.write(fp.read())
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2006-03-06 15:20
Message:
Logged In: YES
user_id=1123998
Your patch will fix the show_qfiles for those entries in the
'in' queue that have unparsed message text, but it will
break it for all other entries that have a
Mailman.Message.Message instance.
Try the attached patch and see if it isn't better. Please
report back on what does and doesn't work for you.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1444447&group_…
Bugs item #1444447, was opened at 2006-03-06 22:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1444447&group_…
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: command line scripts
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Axel Beckert (xtaran)
Assigned to: Nobody/Anonymous (nobody)
Summary: show_qfiles: 'str' object has no attribute 'as_string'
Initial Comment:
With mailman 2.1.5 and Python 2.4 on SuSE Linux 9.3,
show_qfiles throws an error:
python show_qfiles-2.1.7.orig ~/xchange/test.pck
====================> /home/abe/xchange/test.pck
Traceback (most recent call last):
File "show_qfiles-2.1.7.orig", line 74, in ?
main()
File "show_qfiles-2.1.7.orig", line 67, in main
sys.stdout.write(msg.as_string())
AttributeError: 'str' object has no attribute 'as_string'
Removing the ".as_string()" from the source of
show_qfiles fixes the problem.
show_qfiles is still the same in 2.1.7 and still throws
this error. Tested with 2.1.7 and Python 2.4.1 under
SuSE Linux 10.0.
Patch:
--- show_qfiles-2.1.7.orig 2006-03-06
22:38:46.000000000 +0100
+++ show_qfiles-2.1.7 2006-03-06 22:40:27.000000000 +0100
@@ -64,7 +64,7 @@
fp = open(filename)
if filename.endswith(".pck"):
msg = load(fp)
- sys.stdout.write(msg.as_string())
+ sys.stdout.write(msg)
else:
sys.stdout.write(fp.read())
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1444447&group_…
Feature Requests item #669056, was opened at 2003-01-16 14:12
Message generated for change (Comment added) made by decibel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=669056&group_i…
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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Bowman (grantbow)
Assigned to: Nobody/Anonymous (nobody)
Summary: Archive URL in Email
Initial Comment:
When an email goes out, it should have the assigned URL
in the header. This requires you to know what it is as
you send it out which can be tricky. I don't know if
Mailman is designed to handle such a feature. I hope
it is!
----------------------------------------------------------------------
Comment By: Jim C. Nasby (decibel)
Date: 2006-03-04 15:53
Message:
Logged In: YES
user_id=457856
A header would certainly suffice. If you wanted to be really
slick I guess you could allow people to add it to the footer
sent with every email, though I'd never use that.
----------------------------------------------------------------------
Comment By: Oliver Schulze (oliversl)
Date: 2006-03-04 15:04
Message:
Logged In: YES
user_id=70599
DO you mean a header like X-List-*
----------------------------------------------------------------------
Comment By: Bryan Fullerton (fehwalker)
Date: 2005-08-23 15:24
Message:
Logged In: YES
user_id=660772
Some sort of unique identifier (a hash, or some other
permanent ID tag inserted as a header in the .mbox file) for
each message would be very useful if the archive is later
modified and rebuilt.
Currently if a message is removed or added and the archive
rebuilt, search engines must reindex the entire archive to
get the updated URL for each message based on the new
sequence numbers. For large archives this is non-trivial.
+1 for a unique and permanent URL per message, +0 for having
the message URL included in the message/headers.
----------------------------------------------------------------------
Comment By: Jim C. Nasby (decibel)
Date: 2005-08-23 14:39
Message:
Logged In: YES
user_id=457856
I agree this would be extremely handy. I'd post the URL to a
thread about it on mailman-users, but I'm too lazy to find
it in the archive. Of course if there was a URL in the emails...
FWIW, Brad Knowles posted that right now this isn't possible
to do because the archives use a sequence number. If instead
they used a hash of the email, then doing this would be easy.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=669056&group_i…