Usage scenario #4 describes a requirement pertaining to "resent" mail,
but does not define exactly what resent means.
Is this simply mail that goes through MTA relaying, mail that is
redirected via an MTA address alias, mail that is redirected by a
recipient alias, mail that is re-posted such as by a mailing list, or what?
Text in the rest of the opening paragraph appears to intend resent to
mean mail that is re-posted, that is, fully delivered to its initial
addressee and then submitted again by the receiving user agent. There
are a number of scenarios that re-post mail, including the user-level
"forward" command. As such, the scenario, here, should describe
precisely which specific scenario it means.
More generally, I cannot quite tell what this scenario is trying to
demonstrate. As nearly as I can tell, all of the discussion about
signing by Alice is irrelevant, since the later focus seems to be on
signing by the re-poster, Bob.
At any rate, the language "a published practice of signing all messages
sent from Alice's domain to Bob's mailing list" seems to suggest
publishing per-recipient practices. I suspect that's not what was intended.
Possible alternate language:
For example, Alice sends a message to Bob. Alice's rfc2822.From
field domain is used to sign the message and that domain publishes
a statement that all mail with that domain in the From field is
signed.
Lastly, the statement
"Bob merely wants to assert his part in the chain of accountability
for the benefit of the ultimate receivers. It would be useful for
this practice to be encouraged as it gives a more accurate view of
who handled the message"
implies that a long string of signatures by every node that handled the
message would be a good idea.
Does the working group really believe that? I suspect there are some
serious performance impact issues, here.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html