Re: Resending

[dreschs@mpd.tandem.com (Sten Drescher)]

davidk@lysator.liu.se (David K}gedal) said:

DK> dreschs@mpd.tandem.com (Sten Drescher) writes:
>> Resent-Message-ID is in RFC 822 as a reference field, and it is a
>> Good Thing - for example, I use procmail/formail to save 10KB of
>> Message-IDs, and drop duplicates.  The main use for this is in
>> mailing lists - like right now.  If you drop duplicates, you will see
>> this once.  If you don't, you'll see it twice - once from me, and
>> once from the list. If you bounce a message to me, without
>> alteration, I'd want it to be dropped if I've already received it
>> elsewhere.

DK> Yes, I use Gnus to read this, so I only have to see it once, but
DK> aren't you talking about Message-ID? Where does Resent-Message-ID
DK> come into all this?

	It's in RFC 822.  But rereading the RFC, it doesn't work quite
the way I thought it did (the original Message-ID should be untouched).
Still, putting the Resent-Message-ID field in (which, like Message-ID,
is optional in the RFC) is prolly a good thing, since the Resent-
headers are supposed to parallel the normal headers.  But a parallel
question: goes Gnus know to supercede existing Resent- headers, either
by prepending them with Also- or Old- (I prefer Also-), or simply
stripping them out?  I can easily imagine a message getting resent more
than once, and:

rfc822>      4.2.  FORWARDING

[...]

rfc822> Note: In general, the "Resent-" fields should be treated as
rfc822> containing a set of information that is independent of the set
rfc822> of original fields.  Information for one set should not
rfc822> automatically be taken from the other.  The interpretation of
rfc822> multiple "Resent-" fields, of the same type, is undefined.

-- 
#include <disclaimer.h>				/* Sten Drescher */
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3