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

[John A. Martin]

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

    baw> On Sun, 2003-09-28 at 05:13, Harald Meland wrote:
    >> [Barry Warsaw]
    >>
    >> > I really really want to use something like message-ids to
    >> > generate message file names.  I want to be able to generate
    >> > links to archived messages in the footers,

In the header, please.  All messages have headers, not all have
footers.  Footers are optional, no?  This will go on the wire, right?

Also, it would be nice if the URL/link/filename, or some other token,
were serialized in some way so that a subscriber could tell easily
(like by looking at the fill headers, whether he had actually received
all list mail and which he was missing if any.  Smartlist, IIRC, did
that nicely in the header.

    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.

What happened to the notion that archives are supposed to represent a
true record of what was "on the wire"?  Why should mailing list
managers take liberties that are inappropriate to MTAs other than
adding to, but not altering nor deleting anything either in the header
or the body.  The standards define, although somewhat loosely, how
"Resent-" header fields are to be employed but "X-" header fields are
not even mentioned in rfc2822.

There have been several suggestions recently that would break the
notion that list archives be a true record of what was on the wire.
For public mailing lists in particular much would be lost if the lists
own archives could be shown to differ from archives taken off the wire
by others.  We do not rewrite history and we must not be seen to be
rewriting history by altering even esoteric details.  I know of
several instances where the availability of accurate public archives
that were easily corroborated by other archives have simplified
handling issues that might otherwise been very hard to deal with.  A
simple public example is the email in a mailing list archive that for
several years was cited by URL in an early infamous Nigerian
spam/scam.  The ability to point to that email in the context of a
long established mailing list concerning civic affairs in Nigeria
deflected many would be actions against the organization running that
list and those who hosted the mailing list service.

Mailman presumably serves many uses besides public mailing lists.
Many lists may not need to maintain their archives as a public record.
However, unless you wish to make Mailman unsuitable for those that
need accurate archives I suggest that you make it possible for the
site to option individual lists in a way that permits the archives to
serve as a public record of what was on the wire.  If you must munge
the archives I suggest you arrange options such that the site
administrator can coerce certain lists to have accurate archives while
leaving the option open for other lists.

I also urge that the archive not break signatures on signed mail.

    baw> (note that we already do this for NNTP posted messages, and
    baw> there has been some off-list discussion about that).

I am not as conversant with either the standards nor the practice for
NNTP but IIRC news archives have always been supposed to represent
what was on the wire, no?

        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/20030928/6a19cee6/attachment.bin