On 11. 6. 2012, at 21:27, Janne Snabb wrote: > With the feature that I am suggesting my mail system could tell me that > "we have positively authenticated that this e-mail was sent to us by a > server which is named mailserver.$my_bank.com". I could be quite > confident that the e-mail actually arrived from my bank. Equally > confident as when https connection to www.$my_bank.com presents a server > certificate identified by _443._tcp.www.$my_bank.com TLSA record. My > receiving MTA could make the authentication results available to my MUA > either using the "Authentication-Results" header or by some other > underlying mechanism.
We already have different technologies for that - DKIM, S/MIME... I am not sure that reinventing the wheel for a <n>-th time, because we failed before, would actually help anything > Obviously this overlaps with some other technologies. My bank could sign > their e-mails using PGP or S/MIME, but in reality almost nobody except > geeks does that because of various difficulties (the DANE + S/MIME work > might finally make S/MIME signatures automatically verifiable). The difficulty mainly lies in the presentation that information to the end user. Your proposal doesn't really help with that. It would be yet > DANE + S/MIME and DANE/DANCE + SMTP would be complementing each other, > working on different levels of the e-mail infrastructure. And end-user would be totally confused. You seem to forgot the fact that SMTP is a bunch of loosely connected servers which might or might not relay your email. Try to answer following questions: How is your proposal better than DKIM? How is your proposal better than S/MIME? (and/or PGP) How would you present the information that the email came through two or more SMTP relays before it has reached you? <chair hat on> I am not even sure this belongs here. It changes the semantics of SMTP protocol and since we don't have a SMTP WG (now) I think it's more suitable to individual submission in App area. It seems to me that this doesn't change any semantics of DANE protocol (short summary: "hey, receiving MTA - check TLSA record of the sending MTA"). But of course the WG will is my will, so if you want to take this work into the WG, we can try to recharter and convince our AD that this really belongs here. But it would take a lot of strong arguments to convince me and not to mention our beloved AD :). </chair hat on> O. -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:[email protected] http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
