Tony Finch wrote:
[I've removed spf-discuss from the Cc: and replaced
ietf-mxcomp by ietf-smtp for the 2476bis 8.1 issue]
[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 Wiliam'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
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
