Subject: Resent-* oddities (was: Additional appeal against publication of draft-lyon-senderid-* [...])

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Sep 2005 08:45:03 +0200

Tony Finch wrote:

>> the author can't say "updates 2822", how should he fix it ? 
>> As you said the 822 issue is mentioned in the senderid-pra
>> draft.

> Regarding RFC 822, the S-ID draft doesn't mention the fact
> that a large proportion of software which does something
> useful with Resent- headers still implements the 822 syntax,
> not the 2822 syntax.

Except from all PRA-purposes and maybe MUAs displaying these
Resent-* header fields somehow (822 or 2822):  What other uses
do you have in mind ?

Maybe that was discussed somewhere in MARID last year, in that
case I either missed it or didn't get it.

A related issue, apparently 2822 twisted the syntax (more than
one Resent-* block allowed) _and_ the semantics.  Dave's "old"
822 concept could reflect "forwarding" (maybe - I'm not sure).

If that's true 822-Resent-* and PRA are semantically similar,
the only missing piece would be to either allow more than one
"block" (like 2822), or "invalidate" old Resent-* header fields
somehow, e.g. William's Original-* idea.

While I'm at it:  How's that supposed to work with RfC 2476bis
8.1 "MAY add Sender" ?  Apparently 2476bis 8.1 is still based
on the old 822-concept of Resent-* (?)

Or does it ignore the issue ?  Is this part of the PRA-mess in
fact "our" fault (for a definition of TINW including everybody
who reviewed the gellens-submit drafts) ?

Of course I watched 2476 6.1 (and also 8.1), it's essential for
stuff like draft-hutzler-spamops or "op=auth", but something
with Resent-* is very odd, and it's not necessarily PRA.  Bye

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Sep 2005 14:43:10 +0100

> Resent-* header fields somehow (822 or 2822):  What other uses

Ignoring PRA, there are two current sides to the handling of Resent-*:
message submission and message display. An 822 display end can probably
muddle along OK when presented by a 2822 message. An 822 message
submission server will probably do something wrong when fixing up a 2822
message that has been re-sent more than once. A 2822 submission server
will have to have some fairly good heuristics to gracefully handle 822
re-sent messages. Things get even more interesting if an 822-re-sent
message is then 2822-re-sent, because the header order of the original
re-sending has to be fixed.

Sender-ID effecively requires that this kind of submission server fix-up
must be implemented by MTAs and MDAs that do aliasing / redirecting /
forwarding.

> on the old 822-concept of Resent-* (?)

It doesn't address Resent-* at all so one would have to work out for
oneself how a submission server should treat them. This is clearly a bug.
(Is it too late to fix submit-bis now it is in the RFC Editor queue?)
Specifying what to do with them is, however, tricky. Sender-ID lacks this
specification too.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.