>>>>> "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
pgp00000.pgp
Description: PGP signature
_______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
