3 ms·
> Other people being able to verify that an email really was sent by me does serve my interests, because such verification establishes trust. DKIM, the technol
by nulbyte 3y ago
> Other people being able to verify that an email really was sent by me does serve my interests, because such verification establishes trust.
DKIM, the technology considered by the article, does not prove this. The D stands for domain; it asserts nothing about the user that may have sent the email. Even if the domain is yours, you might delegate to another service or two, or you may have more than one user, or some automation in place. In any case, the recipient has little, if any, way to verify that and in all likelihood doesn't care that much; if they did, they wouldn't be relying on DKIM.
> There are very few legitimate situations where you don't want non-repudiation...
As a service provider, I'd probably want this. If it gets me out from the middle of someone else's dispute and doesn't have an ill effect on the service otherwise, I'd welcome it.
- A1kmm 3y agoBut there is a chain: 1) the mail provider only allows outgoing mail with a particular Return-Path / Envelope Sender / From header if it has done authorisation checks to ensure the sender is allowed to use that address, 2) the mail provider DKIM-signs their outgoing mail. The combination of 1 and 2 work together. Yes, the mail provider could impersonate you, or could fail to do (1) correctly, but that is a different threat model to one where having no verification at all is okay.