>>Note that to validate the message, the app needs access to not only the >>signed header fields, but also the body, that the value of bh= is based upon.
Of course. That’s why I suggested that content validation should be ignored. Only headers should be validated. Since the content is "signed" using bh= hash, the hash can be ignored and everything else can be validated. This of course puts some responsibility on the user that is scanning the QR code, to ensure the details (from, to, date, subject) matches up with the email they are seeing on the screen, and that "date" is not too far in the past, so the QR code is not stolen from a legitimate email. Since the To: header field is included in DKIM and QR code, it would mean a fraudster somehow needs to be able to gain access to the victim's mailbox to be able to mint a email that matches a QR code. The idea here is that a end-user should be able to scan'n'verify a email by QR-code and not have to worry about phishing. Since the details about who signed the email and the data in email comes out in clear, it will be very evident if a emai from a bank is signed by "russianwebhost.ru" or similar and thus alert the user about phishing. >> can implement new standards Its about excluding the client and the receiving server from the equation. If anyone - regardless of email operator or receiving server or client - can download a app and scan a QR code to ensure an email is not phishing, I think it gets traction, especially since the QR code would be visible in email, people would look up "Why does all email from Paypal now include a QR code" and they find out about the verification. >>Are there still so many MUAs with no DKIM add-on? MUAs need to include it per default for it to get traction. _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
