[repost after a screw-up on my side, thread started on the general
list, ietf-mxcomp replaced by ietf-smtp for the 2476bis 8.1 issue]
Tony Finch wrote:
[about Resent-* in 822 / 2822 / PRA / 2476(bis) 8.1]
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.
Where's the problem with an 2822 "resender" ? I'm not sure
about your term "submission server", as far as 2822 (excl. PRA)
is concerned a "resender" is a MUA controlled by a human user.
It (the 2822-agent) only has to insert its own Resent-block on
top of all old Resent-header fields. No fixing necessary, or
do you have an example ? For any old Resent-header fields it's
garbage in - garbage out. Good enough for PRA step 1.
For an 822 "resender" (assuming again that it's a MUA) there
are essentially three cases:
1 - it removes or renames old Resent-* crap before inserting
its own Resent-* header fields => no problem with PRA.
2 - it's ignorant but at least it follows a similar strategy
as 2822-"resenders" inserting its stuff at the top => no
problem with PRA. Maybe it's impossible to guess who
created which Resent-Message-ID, but that's no PRA issue.
3 - it's ignorant and inserts it's Resent-* elsewhere, e.g.
at the end of the header => bogus PRA FAILs. This "bug"
is documented (claiming that it's rare, for an experiment
that might be good enough, as long as they stay away from
the other "experiment" v=spf1 with this gambling attitude)
Sender-ID effecively requires that this kind of submission
server fix-up must be implemented by MTAs and MDAs that do
aliasing / redirecting / forwarding.
Yes, there are serious reasons why co-opting non-voluntary
participants into this mess is _wrong_ But that's the other
appeal, not William's appeal. What William said (apparently
supported by Wayne and maybe also you) was that it can't work:
It's broken by design, even as an experiment we could as well
decree FAILURE plus HISTORIC now and be done with it. That's
_far_ more serious than the first appeal (supported by me).
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?)
Probably too late, and I haven't the heart to ask the authors,
it took them ages to get the DS approval. Essentially 2476bis
8.1 "MAY add Sender" ignores all cases of Resent-* (incl. PRA).
So far my theory was that PRA _could_ work in most cases where
it would otherwise fail miserably, if all MSAs are upgraded to
"SHOULD add Sender" (only admins loving fights with privacy
officers would try to do this, but that's no technical issue).
If 8.1 is already broken by design for the Resent-* case, this
won't happen for too many reasons, technical reasons. That's
not the fault of PRA, but ignoring it doesn't make it better.
Specifying what to do with them is, however, tricky.
It's about as tricky as the PRA spec., so probably nothing the
2476bis authors will try in AUTH48. When they go for STD it
should be documented near 8.1.
Sender-ID lacks this specification too.
Let's see what the IESG does about William's appeal, a decision
like "you can't do this now, because Resent-* in 822 / 2822 /
2476bis is too messy to mess around with making it worse" would
be, hm... honest ?
Now I'm seriously lost with op=pra, so far I have this text in
the "security considerations"...
| While the "pra" property offers a way for this explicit approval in
| the case of a "PRA" identity, it does not solve any of the underlying
| technical problems with this approach. Receivers should treat all
| PRA-results with utmost care.
...and another warning in the op=pra section:
| Enforced submission rights for MSAs in [I-D.gellens-submit-bis] do
| not guarantee a match of any address in the 2822-From header field
| with the "MAIL FROM" identity, and they also do not guarantee the
| presence of a matching 2822-Sender header field. For more details
| about these problems see [RFC2822] and compare sections 6.1 and 8.1
| in [I-D.gellens-submit-bis].
The latter (8.1) is obviously not good enough. :-( Bye, Frank