[Mailman-Developers] "@" in mail **text** gets replaced inarchives

[John A. Martin]

>>>>> "Harald" == Harald Meland
>>>>> "Re: [Mailman-Developers] "@" in mail **text** gets replaced inarchives"
>>>>>  Sun, 28 Sep 2003 22:09:09 +0200

    >>>>>>> "baw" == Barry Warsaw "Re: [Mailman-Developers] "@" in
    >>>>>>> mail **text** gets replaced inarchives" Sun, 28 Sep 2003
    >>>>>>> 09:45:32 -0400

    baw> we could rewrite all message-id headers when we accept the
    baw> message.  That would guarantee uniqueness but it would break
    baw> the correlation of message-ids between list copies and direct
    baw> copies.  Is that bad?
    >>
    >> Yes.  The RFCs are clear that MTAs must not muck with
    >> Message-Id other that to create one if there is none.

    Harald> It is not clear to me that Mailman *is* an MTA.  It is not
    Harald> an SMTP server, and is not (necessarily) an SMTP client.

To have been precise perhaps I should have said something like "a mail
agent must not muck with an existing Message-Id except as specified by
the applicable standards".  The Applicable Standards, to quote for
example rfc2822,, apply as follows:

   This standard specifies a syntax for text messages that are sent
   between computer users, within the framework of "electronic mail"
   messages.

The applicable standards govern what goes on the wire and therefore
what Mailman causes to be put on the wire through a MTA should be
compliant.

    Harald> However, even if Mailman isn't an MTA, it would be nice if
    Harald> it *mostly* tries to follow the MTA rules.

    Harald> (As a side note, I am unable to find *clear* references to
    Harald> the effect of your statement in RFCs 2821 or 2822.)

Rfc2822 Section 3.6.4 (the first paragraph below is the same paragraph
you quoted elsewhere)

   [[ ... ]]

   The "Message-ID:" field provides a unique message identifier that
   refers to a particular version of a particular message.  The
   uniqueness of the message identifier is guaranteed by the host that
   generates it (see below).  This message identifier is intended to be
   machine readable and not necessarily meaningful to humans.  A message
   identifier pertains to exactly one instantiation of a particular
   message; subsequent revisions to the message each receive new message
   identifiers.

   Note: There are many instances when messages are "changed", but those
   changes do not constitute a new instantiation of that message, and
   therefore the message would not get a new message identifier.  For
   example, when messages are introduced into the transport system, they
   are often prepended with additional header fields such as trace
   fields (described in section 3.6.7) and resent fields (described in
   section 3.6.6).  The addition of such header fields does not change
   the identity of the message and therefore the original "Message-ID:"
   field is retained.  In all cases, it is the meaning that the sender
   of the message wishes to convey (i.e., whether this is the same
   message or a different message) that determines whether or not the
   "Message-ID:" field changes, not any particular syntactic difference
   that appears (or does not appear) in the message.

Rfc822 Section 4.6.1 (in its entirety):

             This field contains a unique identifier  (the  local-part
        address  unit)  which  refers to THIS version of THIS message.
        The uniqueness of the message identifier is guaranteed by  the
        host  which  generates  it.  This identifier is intended to be
        machine readable and not necessarily meaningful to humans.   A
        message  identifier pertains to exactly one instantiation of a
        particular message; subsequent revisions to the message should
        each receive new message identifiers.

Rfc2822 in this case merely codifies long established practice
interpreting rfc822.  Rfc2822 Appendix A.3 may be helpful for the
present discussion.

To test for compliance with the rfc2822 determination "whether this is
the same message or a different message" one might stipulate that if
the PGP signature verifies it is the same message, if the PGP
signature does not verify it is a different message.  As can be seen
with the version of this here message that Mailman will send, a
trailer can be added to the body without breaking the signature.  The
rule might be "if you break the signature, it is a new message and
needs (at least) a new Message-Id" (One certainly can see by
inspection what would break a signature without actually verifying the
signature, right?)

    Harald> Um.  Mailman lists have numerous configuration options for
    Harald> changing messages (e.g. adding footers) before they are
    Harald> sent to the list members, and it has had such options
    Harald> since time immemorial.

Who reads the RFCs to say that footers cannot be added without
changing the message?

Other munging of the message is IMHO unsuitable for public archives
and have not been obligatory AFIK.

    Harald> As such, Mailman has to choose; should the messages be
    Harald> archived as they appeared on the wire _coming in_ or
    Harald> _going out_?  To me, it is obvious that messages in the
    Harald> archives should reflect, as closely as possible, the
    Harald> messages members receive.

Agreed, the archive should record what Mailman put on the wire.  No
choice required!  At least as you put it.  I suppose a case could be
made for archiving the mail received "from the wire" but I haven't
thought of a good reason why that would be better.

    Harald> * To my mind it would not be obviously wrong to view
    Harald>    Mailman as the *generator* of messages, at the very
    Harald>    least in the cases where it is obvious that the
    Harald>    previous generator didn't do its job of guaranteeing
    Harald>    message-id uniqueness properly.

Why?

ISTM the problem you are trying to solve is how to identify the
archive image of the message.

Why not construct a URL containing a scrubbed Message-Id (as Brad
Knowles has indicated) and a serial number (as I have indicated)?
Such a URL should go into the "List-Archive" header field pointing to
the specific message without doing violence to rfc2369 Section 3.6,
right?

        jam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 154 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030929/da4e6908/attachment.bin