On Thu, 1 Sep 2005, Frank Ellermann wrote: > > > 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 ? 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. > 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-* (?) 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 <dot@xxxxxxxx> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf