On 5/31/2019 3:59 AM, Douglas E. Foster wrote:
Agency and signatures are well understood legal concepts. 3000 years
The signature at issue here is done with DKIM.
Are you sure you are clear about the what the agency is it vets and what
the scope of use for that vetting is? I suspect you are assuming a
different type and scope of authentication than DKIM is intended to
perform. It's not that your goal is unreasonable -- and indeed, s/mime
and openpgp seeks to perform it -- it's that DKIM wasn't designed to do
that. DKIM was designed for use during tranfer to the point of
delivery. For this discussion, that means to the list processor (mailbox)
ago, people sealed their letters with a signet ring stamped in warm
clay. Signing technologies have changed in that time, but the
principle has not. A courier is responsible for keeping the signed and
Please note my earlier point about delivery and re-posting. That
implies a role for list processing that is considerably more than a
courier's.
sealed part of a message unaltered. Envelope marks are acceptable.
A digital signature is supposed to provide non-repudiation. If I submit
DKIM is a transfer-level signature. That is, really, MTA-MTA (or,
really, MTA-MDA).
A list processor is an MUA-level actor. (cf, RFC 5598.)
There are some obvious use-cases for MTA changes to a message, and we
would do well to document and address them.
Perhaps, but that's not at issue here.
The first that comes to mind is MTA comment fields.
Huh?
- A spam filter wants to add a tag indicating that the message is
suspicious, but not sufficiently suspicious to be blocked.
IETF would do well to specify a mechanism for MTAs to add information
which MUAs present to the user, while identifiying that that the
information came from the MTA rather than the original sender.
You mean like adding a header field, outside of the ones signed by DKIM?
That's already permitted. It's one of the reasons that the signer gets
to decide what header fields to cover.
However, it looks as if you think presenting such information to users
will be useful. It won't.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
