FAQ
I just upgraded to Mailman 2.1.2 and regenerated my archives.
After the process was finished, some messages was given todays date, and
was therefor misplaced in the archive hierarcy.

It seems to me that Mailman/Pipermail does not understand this kind of
date-header:
Date: 22 Mar 2002 13:26:16 +0100
while this one is ok:
Date: Fri, 22 Mar 2002 13:08:56 +0100

The first mail is posted using GNUS/Emacs, while the second is posted
using Outlook Express.

Am I right? Is this a known bug, or is it supposed to be like this?


Kind regards,
Stig

Search Discussions

  • Jon Carnes at May 6, 2003 at 1:52 pm
    I have no doubt <without even looking at the code> that this is a
    pipermail problem. Unfortunately Pipermail is not maintained as well as
    Mailman, and though Mailman ships with Pipermail, they are separate
    projects.

    Barry would like to find some hale and hardy folks to modernize and
    maintain Pipermail. Feel free to volunteer!

    Jon Carnes
    On Tue, 2003-05-06 at 09:35, Stig Petterson wrote:
    I just upgraded to Mailman 2.1.2 and regenerated my archives.
    After the process was finished, some messages was given todays date, and
    was therefor misplaced in the archive hierarcy.

    It seems to me that Mailman/Pipermail does not understand this kind of
    date-header:
    Date: 22 Mar 2002 13:26:16 +0100
    while this one is ok:
    Date: Fri, 22 Mar 2002 13:08:56 +0100

    The first mail is posted using GNUS/Emacs, while the second is posted
    using Outlook Express.

    Am I right? Is this a known bug, or is it supposed to be like this?


    Kind regards,
    Stig

    ------------------------------------------------------
    Mailman-Users mailing list
    Mailman-Users at python.org
    http://mail.python.org/mailman/listinfo/mailman-users
    Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
    Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/

    This message was sent to: jonc at nc.rr.com
    Unsubscribe or change your options at
    http://mail.python.org/mailman/options/mailman-users/jonc%40nc.rr.com
  • Richard Barrett at May 6, 2003 at 5:00 pm
    If you look at the mailman-users user archive at
    http://mail.python.org/pipermail/mailman-users you will see clear evidence
    of a problem in posting date handling by pipermail.

    In the current May 2003 archive, Jon Carnes <jonc at nc.rr.com> response to
    an original post from Stig Petterson <petterso at online.no> appears after
    Stig's post on the date index for the archive not before it. I believe this
    is caused by a bug in the pipermail archiver for which I have recently
    posted a patch for MM 2.1.2, see:

    http://sourceforge.net/tracker/index.php?funcÞtail&aids2366&group_id3&atid0103

    This may or may not be Stig's original problem but it is definitely a
    problem for lists where people from different time zones are posting and
    can give a false impression in the ordering of events on a list.
  • Jon Carnes at May 6, 2003 at 5:42 pm
    There is also a switch that you can use in Pipermail so that it ignores
    the time told to it by the email and instead uses the local time that
    the email arrived at the server - actually Mailman replaces the Date:
    field in the message with the local time.

    You may find this to be a good solution for your problem (not *you*
    Richard... and thanks for the patch!).

    === From ~mailman/Mailman/mm_cfg.py ==# This sets the default `clobber date' policy for the archiver.
    # When a message is to be archived either by Pipermail or an
    # external archiver, Mailman can modify the Date: header to be
    # the date the message was received instead of the Date: in the
    # original message. This is useful if you typically receive
    # messages with outrageous dates. Set this to 0 to retain the
    # date of the original message, or to 1 to always clobber the
    # date. Set it to 2 to perform `smart overrides' on the date;
    # when the date is outside
    # ARCHIVER_ALLOWABLE_SANE_DATE_SKEW (either too early or too late),
    # then the received date is substituted instead.
    ARCHIVER_CLOBBER_DATE_POLICY = 2
    ARCHIVER_ALLOWABLE_SANE_DATE_SKEW = days(15)

    =====
    Jon Carnes
    On Tue, 2003-05-06 at 13:00, Richard Barrett wrote:
    If you look at the mailman-users user archive at
    http://mail.python.org/pipermail/mailman-users you will see clear evidence
    of a problem in posting date handling by pipermail.

    In the current May 2003 archive, Jon Carnes <jonc at nc.rr.com> response to
    an original post from Stig Petterson <petterso at online.no> appears after
    Stig's post on the date index for the archive not before it. I believe this
    is caused by a bug in the pipermail archiver for which I have recently
    posted a patch for MM 2.1.2, see:

    http://sourceforge.net/tracker/index.php?funcÞtail&aids2366&group_id3&atid0103

    This may or may not be Stig's original problem but it is definitely a
    problem for lists where people from different time zones are posting and
    can give a false impression in the ordering of events on a list.
  • Richard Barrett at May 6, 2003 at 9:26 pm
    Jon

    I sent this earlier to Stig petterso at online.no but managed to screw up
    putting you and mailman-users on the Cc

    Richard

    I said to Stig:

    Stig

    In response to your original query, I think there may be an issue with the
    version of email,Utils.parsedate_tz() function that is shipped with Mailman.

    Mailman ships with the email module version 2.5.1 and MM uses that in
    preference to any version of the email module that is installed with your
    Python version.

    The first form of date you cited is not parsed successfully and pipermail
    reverts to other alternatives, ultimately using now if all else fails.

    This looks to be a problem with a standard library module rather than a
    pipermail problem per se. Whether this is a bug or a feature in email-2.5.1
    I have yet to determine.

    The following results are from running Python on a terminal using Python
    2.2.2 and you can see the difference in parsing the date between the
    version of email that shipped with Python 2.2.2 and the alternative version
    (which is loaded instead as a result of the import paths statement) which
    shipped with MM 2.1.2


    mailman at mailman2:/mailman/run/bin> python
    Python 2.2.2 (#3, Feb 11 2003, 16:57:53)
    [GCC 2.95.3 20010315 (SuSE)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    from email.Utils import parsedate_tz, mktime_tz
    d1 = '22 Mar 2002 13:26:16 +0100'
    p1 = parsedate_tz(d1)
    print p1
    (2002, 3, 22, 13, 26, 16, 0, 0, 0, 3600)
    >>>
    mailman at mailman2:/mailman/run/bin> python
    Python 2.2.2 (#3, Feb 11 2003, 16:57:53)
    [GCC 2.95.3 20010315 (SuSE)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    import paths
    from email.Utils import parsedate_tz, mktime_tz
    d1 = '22 Mar 2002 13:26:16 +0100'
    p1 = parsedate_tz(d1)
    print p1
    None
    >>>
    mailman at mailman2:/mailman/run/bin>

    I will take a look at the email.Utils source code and see if I can sort out
    some sort of patch for this. If I cannot see a solution, I will send Barry
    Warsaw, who I believe also 'owns' the email module, a problem report.

    Regards

    Richard


    In http://mail.python.org/pipermail/mailman-users/2003-May/028679.html

    Stig said;

    I just upgraded to Mailman 2.1.2 and regenerated my archives.

    After the process was finished, some messages was given todays date, and
    was therefor misplaced in the archive hierarcy.

    It seems to me that Mailman/Pipermail does not understand this kind of
    date-header:

    Date: 22 Mar 2002 13:26:16 +0100

    while this one is ok:

    Date: Fri, 22 Mar 2002 13:08:56 +0100

    The first mail is posted using GNUS/Emacs, while the second is posted using
    Outlook Express.

    Am I right?

    Is this a known bug, or is it supposed to be like this? Kind regards,

    Stig
  • Jon Carnes at May 7, 2003 at 12:02 am
    Thanks Richard,

    I hate to say this, but I'm not seeing the same results as you. I
    duplicated your test and got the same answer for both tests.

    Here is my test with the "import paths":

    [jonc at anncons /usr/local/mailman/bin]$ python
    Python 2.2.2 (#2, Feb 5 2003, 10:40:08)
    [GCC 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk)] on linux-i386
    Type "help", "copyright", "credits" or "license" for more information.
    import paths
    from email.Utils import parsedate_tz, mktime_tz
    d1 = '22 Mar 2002 13:26:16 +0100'
    p1 = parsedate_tz(d1)
    print p1
    (2002, 3, 22, 13, 26, 16, 0, 0, 0, 3600)
    >>>

    Thanks - Jon
    On Tue, 2003-05-06 at 17:26, Richard Barrett wrote:
    Jon

    I sent this earlier to Stig petterso at online.no but managed to screw up
    putting you and mailman-users on the Cc

    Richard

    I said to Stig:

    Stig

    In response to your original query, I think there may be an issue with the
    version of email,Utils.parsedate_tz() function that is shipped with Mailman.

    Mailman ships with the email module version 2.5.1 and MM uses that in
    preference to any version of the email module that is installed with your
    Python version.

    The first form of date you cited is not parsed successfully and pipermail
    reverts to other alternatives, ultimately using now if all else fails.

    This looks to be a problem with a standard library module rather than a
    pipermail problem per se. Whether this is a bug or a feature in email-2.5.1
    I have yet to determine.

    The following results are from running Python on a terminal using Python
    2.2.2 and you can see the difference in parsing the date between the
    version of email that shipped with Python 2.2.2 and the alternative version
    (which is loaded instead as a result of the import paths statement) which
    shipped with MM 2.1.2


    mailman at mailman2:/mailman/run/bin> python
    Python 2.2.2 (#3, Feb 11 2003, 16:57:53)
    [GCC 2.95.3 20010315 (SuSE)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    from email.Utils import parsedate_tz, mktime_tz
    d1 = '22 Mar 2002 13:26:16 +0100'
    p1 = parsedate_tz(d1)
    print p1
    (2002, 3, 22, 13, 26, 16, 0, 0, 0, 3600)
    mailman at mailman2:/mailman/run/bin> python
    Python 2.2.2 (#3, Feb 11 2003, 16:57:53)
    [GCC 2.95.3 20010315 (SuSE)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    import paths
    from email.Utils import parsedate_tz, mktime_tz
    d1 = '22 Mar 2002 13:26:16 +0100'
    p1 = parsedate_tz(d1)
    print p1
    None
    mailman at mailman2:/mailman/run/bin>

    I will take a look at the email.Utils source code and see if I can sort out
    some sort of patch for this. If I cannot see a solution, I will send Barry
    Warsaw, who I believe also 'owns' the email module, a problem report.

    Regards

    Richard


    In http://mail.python.org/pipermail/mailman-users/2003-May/028679.html

    Stig said;

    I just upgraded to Mailman 2.1.2 and regenerated my archives.

    After the process was finished, some messages was given todays date, and
    was therefor misplaced in the archive hierarcy.

    It seems to me that Mailman/Pipermail does not understand this kind of
    date-header:

    Date: 22 Mar 2002 13:26:16 +0100

    while this one is ok:

    Date: Fri, 22 Mar 2002 13:08:56 +0100

    The first mail is posted using GNUS/Emacs, while the second is posted using
    Outlook Express.

    Am I right?

    Is this a known bug, or is it supposed to be like this? Kind regards,

    Stig
  • Tokio Kikuchi at May 7, 2003 at 12:27 am
    Hi, Jon and Richard.

    I am with Richard. Following patch fix this and I really don't
    understand why this else close is required.

    Tokio

    --- /home/mailman/src/mailman-2.1.2/misc/email-2.5.1/email/_parseaddr.py
    Mon Mar 31 05:21:29 2003
    +++ _parseaddr.py Fri May 2 08:45:34 2003
    @@ -52,11 +52,11 @@
    if data[0].endswith(',') or data[0].lower() in _daynames:
    # There's a dayname here. Skip it
    del data[0]
    - else:
    - i = data[0].rfind(',')
    - if i < 0:
    - return None
    - data[0] = data[0][i+1:]
    + #else:
    + # i = data[0].rfind(',')
    + # if i < 0:
    + # return None
    + # data[0] = data[0][i+1:]
    if len(data) == 3: # RFC 850 date, deprecated
    stuff = data[0].split('-')
    if len(stuff) == 3:





    Jon Carnes wrote:
    Thanks Richard,

    I hate to say this, but I'm not seeing the same results as you. I
    duplicated your test and got the same answer for both tests.

    Here is my test with the "import paths":

    [jonc at anncons /usr/local/mailman/bin]$ python
    Python 2.2.2 (#2, Feb 5 2003, 10:40:08)
    [GCC 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk)] on linux-i386
    Type "help", "copyright", "credits" or "license" for more information.
    import paths
    from email.Utils import parsedate_tz, mktime_tz
    d1 = '22 Mar 2002 13:26:16 +0100'
    p1 = parsedate_tz(d1)
    print p1
    (2002, 3, 22, 13, 26, 16, 0, 0, 0, 3600)


    Thanks - Jon
    On Tue, 2003-05-06 at 17:26, Richard Barrett wrote:

    Jon

    I sent this earlier to Stig petterso at online.no but managed to screw up
    putting you and mailman-users on the Cc

    Richard

    I said to Stig:

    Stig

    In response to your original query, I think there may be an issue with the
    version of email,Utils.parsedate_tz() function that is shipped with Mailman.

    Mailman ships with the email module version 2.5.1 and MM uses that in
    preference to any version of the email module that is installed with your
    Python version.

    The first form of date you cited is not parsed successfully and pipermail
    reverts to other alternatives, ultimately using now if all else fails.

    This looks to be a problem with a standard library module rather than a
    pipermail problem per se. Whether this is a bug or a feature in email-2.5.1
    I have yet to determine.

    The following results are from running Python on a terminal using Python
    2.2.2 and you can see the difference in parsing the date between the
    version of email that shipped with Python 2.2.2 and the alternative version
    (which is loaded instead as a result of the import paths statement) which
    shipped with MM 2.1.2


    mailman at mailman2:/mailman/run/bin> python
    Python 2.2.2 (#3, Feb 11 2003, 16:57:53)
    [GCC 2.95.3 20010315 (SuSE)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    from email.Utils import parsedate_tz, mktime_tz
    d1 = '22 Mar 2002 13:26:16 +0100'
    p1 = parsedate_tz(d1)
    print p1
    (2002, 3, 22, 13, 26, 16, 0, 0, 0, 3600)
    mailman at mailman2:/mailman/run/bin> python
    Python 2.2.2 (#3, Feb 11 2003, 16:57:53)
    [GCC 2.95.3 20010315 (SuSE)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    import paths
    from email.Utils import parsedate_tz, mktime_tz
    d1 = '22 Mar 2002 13:26:16 +0100'
    p1 = parsedate_tz(d1)
    print p1
    None
    mailman at mailman2:/mailman/run/bin>

    I will take a look at the email.Utils source code and see if I can sort out
    some sort of patch for this. If I cannot see a solution, I will send Barry
    Warsaw, who I believe also 'owns' the email module, a problem report.

    Regards

    Richard


    In http://mail.python.org/pipermail/mailman-users/2003-May/028679.html

    Stig said;

    I just upgraded to Mailman 2.1.2 and regenerated my archives.

    After the process was finished, some messages was given todays date, and
    was therefor misplaced in the archive hierarcy.

    It seems to me that Mailman/Pipermail does not understand this kind of
    date-header:

    Date: 22 Mar 2002 13:26:16 +0100

    while this one is ok:

    Date: Fri, 22 Mar 2002 13:08:56 +0100

    The first mail is posted using GNUS/Emacs, while the second is posted using
    Outlook Express.

    Am I right?

    Is this a known bug, or is it supposed to be like this? Kind regards,

    Stig
  • Barry Warsaw at May 8, 2003 at 3:28 am

    On Tue, 2003-05-06 at 20:27, Tokio Kikuchi wrote:
    I am with Richard. Following patch fix this and I really don't
    understand why this else close is required.
    The else clause is there to handle formats like:

    Wed, 3 Apr 2002 14:58:26 +0800

    Notice the single digit in the day field. So commenting out the else
    clause causes a regression in the test suite. Here's the patch I'm
    going to check in (along with some test cases). I'll tag email 2.5.2
    and check it into Mailman's cvs.

    Thanks and sorry for the delay,
    -Barry
  • Tokio Kikuchi at May 9, 2003 at 12:49 am
    Barry,

    Sorry for my slow response.

    Barry Warsaw wrote:
    On Tue, 2003-05-06 at 20:27, Tokio Kikuchi wrote:

    I am with Richard. Following patch fix this and I really don't
    understand why this else close is required.

    The else clause is there to handle formats like:

    Wed, 3 Apr 2002 14:58:26 +0800
    This passed my test without else close.

    May be this pattern ?
    Wed,3 Apr 2002 14:58:26 +0800
    If you stick to the BNF, you should not insert space between
    the comma and date. :-<
    In RFC2822,
    date-time = [ day-of-week "," ] date FWS time [CFWS]

    Anyway, thank you for the fix.

    Cheers,

    --
    Tokio

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedMay 6, '03 at 1:35p
activeMay 9, '03 at 12:49a
posts9
users6
websitelist.org

People

Translate

site design / logo © 2022 Grokbase