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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

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.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 04 Sep 2005 05:19:50 +0200

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]
>> Resent-* header fields somehow (822 or 2822):  What other
>> uses do you have in mind ?

> 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

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

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Sep 2005 12:40:53 +0100

> is concerned a "resender" is a MUA controlled by a human user.

RFC 2476 recommends server-side message header fix-ups, so that MUAs do
not have to worry themselves with creating globally-unique message-IDs or
correct Date: fields. Submission servers can also fix-up the Sender: field
with the address of the authenticated submitter. If the message is re-sent
then the server needs to fix-up the Resent-Sender: instead, so it needs to
be able to deal with 2822/822 backwards compatibility.

> do you have an example ?

If the message has already been 822-re-sent then its syntax will not be
conformant with RFC 2822. Perhaps a properly conformant MUA (or MSA) would
prefer to fix the old Resent- fields in order to avoid syntax errors.

>     created which Resent-Message-ID, but that's no PRA issue.

It's more common for software to add fields to the end of the header.

> appeal, not William's appeal.

I intended to just address the syntactic problems, not the higher-level
deployment problems.

Tony.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 06 Sep 2005 04:18:38 +0200

Tony Finch wrote:

> RFC 2476 recommends server-side message header fix-ups, so
> that MUAs do not have to worry themselves with creating
> globally-unique message-IDs or correct Date: fields.

Okay, and something like Resent-Message-ID worries me, e.g.
what are mail2news gateways supposed to do ?  Personally I
think that Resent-* is a hopeless case and should be
deprecated.

*Maybe* it's possible to fix it in hypothetical 2822bis and
2476ter RfCs, and if that's done with "we want PRA to work"
in mind PRA might really work.

But my personal interests in this issue are limited to "I've
never got a single Resent-* mail", "MIME message/rfc822 is
better for this purpose", and "so do what you like but stay
away from my mail".

And the latter is the point of the first senderid-appeal.

> Submission servers can also fix-up the Sender: field with the
> address of the authenticated submitter. If the message is
> re-sent then the server needs to fix-up the Resent-Sender:
> instead, so it needs to be able to deal with 2822/822
> backwards compatibility.

Yes.  The method to do this would be somewhat similar to PRA,
starting with "if there is a Resent-* header field" {etc.]

BTW, 2476bis 8.1 talks about "add Sender", not "fix Sender",
that's a major difference.  A potential "fix Sender" should
be better "reject" - or maybe "rename and add", but not just
"replace silently", the latter makes me very nervous.

>>     as 2822-"resenders" inserting its stuff at the top
{...]

> It's more common for software to add fields to the end of the

Then let's forget "maybe PRA could work with case [2]", that
leaves case [3] "PRA doesn't work with the 822 Resent-* idea".

> I intended to just address the syntactic problems, not the
> higher-level deployment problems.

Okay, but the IESG has to do something with William's appeal,
that's a special case of "higher-level deployment problem" ;-)

                          Bye, Frank