4 ms·
1.a.1 I think this is your main fault. You are assuming that end-to-end encrypted message content is equatable to 'insecure' SMTP. The clear text or encrypte
by jocluteseh 12y ago
1.a.1 I think this is your main fault. You are assuming that end-to-end encrypted message content is equatable to 'insecure' SMTP. The clear text or encrypted content of an email message has nothing to do with validating that an email account belongs to a domain and is valid.
SPF validates that the email account holder is valid.
DKIM signs the message and provides a body hash which is validated against the public key in DNS.
DMARC allows the domain owner to say that the message should trashed or passed.
And DNSSEC allows the DNS root to say that the sending domain is the sending domain.
So -- I repeat -- with SPF, DKIM, DMARC, and DNSSEC email validated CA certificates are quite secure.
And, yet, you are unwilling to admit this...
I suggest you read the DKIM RFCs, particularly RFC5585
"2.3. Establishing Message Validity
Though man-in-the-middle attacks are historically rare in email, it is nevertheless theoretically possible for a message to be modified during transit. An interesting side effect of the cryptographic method used by DKIM is that it is possible to be certain that a signed message (or, if l= is used, the signed portion of a message) has not been modified between the time of signing and the time of verifying. If it has been changed in any way, then the message will not be verified successfully with DKIM."
- pyre 12y agoWhile I don't purport myself to be a crypto expert, you can't cite an RFC of a protocol as "proof" that something is secure. For example, if people come up with attacks against DKIM after the RFC is created, they don't issue an errata on the RFC listing all possible attacks.
- deleted 12y ago[deleted]
- rakoo 12y ago> DKIM signs the message and provides a body hash which is validated against the public key in DNS And how do you make sure the public key is correct then ? Well, just use DNSSEC !