Jim Fenton wrote:
I agree that there are perhaps more optimal ways of doing the
verification, but the lead-in to the diagram says it is a
"typical usage flowchart" for DKIM.
Yes, but too simple for what we need for the {censored] mailing
lists mutilating mail bodies and doing interesting "things" wrt
PRA in the header.
For the threats draft not absolutely necessary, but somewhere
we need it, it's also related to the terminology question, and
other discussions about "strong" policies.
Excluding MSAs and MDAs all MTAs get mail from another MTA and
(try to) forward it to the next MTA (if they haven't rejected
it. The typical flow is therefore receive before send even if
you look only at a single MTA.
If you aggregate them into (first) MON / mediator / (final) MRN
it starts to get important, the MX(s) of the mediator check the
signatures if they wish to reject "strong" problems, and the
(re)signing comes much later after the mailing list modified
the mail.
I think it's beneficial to go with the simplest example
possible here.
Generally I like KISS, but with bounce messages (instead of a
clean reject at the border MX) details matter. Admittedly no
point for the threats draft, "DKIM could cause more bounces if
implemented in some naive ways" is no interesting threat. Bye
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html