bounce problem w/ 2.1.11rc1 and GMail
Apparently I've got a problem with this release: if I believe the logs, the bounce processor seems unable to recognize bounces messages coming from googlemail.com ; logs/bounce is full of lines like: Jun 15 01:52:46 2008 (3303) bounce message w/no discernable addresses: <000e0cd286e21d95f3044fa917b5@googlemail.com>
-- Fil
Fil wrote:
Apparently I've got a problem with this release: if I believe the logs, the bounce processor seems unable to recognize bounces messages coming from googlemail.com ; logs/bounce is full of lines like: Jun 15 01:52:46 2008 (3303) bounce message w/no discernable addresses: <000e0cd286e21d95f3044fa917b5@googlemail.com>
Bounce recognition in 2.1.11rc1 is the same as in all the 2.1.10 beta, candidate and final releases.
It is possible that these are spam messages with a googlemail.com message-id being sent directly to a list-bounces addresses. If bounce_unrecognized_goes_to_list_owner is On, the list owner will get a copy of the bounce and you can see if they are real bounces or spam.
If it is a real bounce, send it to me, and I'll update the recognizers.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Bounce recognition in 2.1.11rc1 is the same as in all the 2.1.10 beta, candidate and final releases.
Hi Mark,
in fact I was living with 2.1.6b (ouch!) up till today, and I had disabled the bounce processors; I just upgraded tonight and am checking logs and stuff...
If it is a real bounce, send it to me, and I'll update the recognizers.
Seem real. I'm sending them to you.
Also, reading the code, I understand that the .getDeliveryStatusChangeTime method is not used anywhere (except in bin/export.py and Mailman/Commands/cmd_set.py); wouldn't it be sensible to remove it altogether?
-- Fil
Fil wrote:
in fact I was living with 2.1.6b (ouch!) up till today, and I had disabled the bounce processors; I just upgraded tonight and am checking logs and stuff...
If it is a real bounce, send it to me, and I'll update the recognizers.
Seem real. I'm sending them to you.
Thanks. I have updated bzr at rev 1098 on the 2.1 branch. This patch to SimpleWarning.py will recognize these delay warnings. === modified file 'Mailman/Bouncers/SimpleWarning.py' --- Mailman/Bouncers/SimpleWarning.py 2007-11-12 05:40:15 +0000 +++ Mailman/Bouncers/SimpleWarning.py 2008-06-15 04:04:44 +0000 @@ -1,4 +1,4 @@ -# Copyright (C) 2001-2007 by the Free Software Foundation, Inc. +# Copyright (C) 2001-2008 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -49,6 +49,10 @@ (_c('Delivery attempts will continue to be made'), _c('.+'), _c('(?P<addr>.+)')), + # Googlemail + (_c('THIS IS A WARNING MESSAGE ONLY'), + _c('Message will be retried'), + _c(r'\s*(?P<addr>\S+@\S+)\s*')), # Next one goes here... ]
Also, reading the code, I understand that the .getDeliveryStatusChangeTime method is not used anywhere (except in bin/export.py and Mailman/Commands/cmd_set.py); wouldn't it be sensible to remove it altogether?
The time is set by the setDeliveryStatus method. Since the time is there, it seems reasonable to have a method to get it, even if it isn't widely used. -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks. I have updated bzr at rev 1098 on the 2.1 branch. This patch to SimpleWarning.py will recognize these delay warnings.
Thanks a lot Mark.
I found another minor issue today: my name contains a "รจ", and when I subscribe it is transformed into è in the database. Why not. But then it is presented to me everywhere on the web UI as è which displays the code and not the character. I can live with that but it's a bit ugly :-)
-- Fil
Fil wrote:
I found another minor issue today: my name contains a "=E8", and when I subscribe it is transformed into è in the database.
There may be an issue with your MemberAdaptor. With OldStyleMemberships.py, accented characters are accepted and stored as themselves in the usernames dictionary.
Why not. But then it is presented to me everywhere on the web UI as è which displays the code and not the character. I can live with that but it's a bit ugly :-)
They are only displayed as &#ddd; in the web interface if the language of the page is English. If the list's preferred language is e.g., French, they will display correctly in the admin interface, and if the user's preferred language is e.g., French, they will display correctly on the user's options page.
Granted, the conversion of è to è is ugly, but it would be hard to change. The conversion of \xe8 to è is done by Utils.uncanonstr() which will convert any character that can't be encoded in the relevant character set (us-ascii for English) to the &#ddd; form. Then, in order to protect against XSS attacks, values to be displayed are passed through cgi.escape() which converts the & to &.
The real fix might be for cgi.escape() to be smarter :-)
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
There may be an issue with your MemberAdaptor. With OldStyleMemberships.py, accented characters are accepted and stored as themselves in the usernames dictionary.
Yes you are correct Mark, this escaping is done by MysqlMemberships.py
def escape(self, value):
# transforms accents into html entities (é)
# TODO: find out which language is current (here: uses iso-8859-1)
value = Utils.uncanonstr(value)
# addslashes before " and '
return MySQLdb.escape_string(value)the difficulty is that MySQLdb.escape_string crashes if given non-ascii text.
So I'm modifying MysqlMemberships.py (rev. 94) so that we canonstr() back in getMemberName(). However it's a not ideal; I don't like that idea very much as it means that inside the db it is stored as è. Should probably be utf-8.
-- Fil
participants (2)
-
Fil -
Mark Sapiro