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
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com