Hi Viktor, Viktor Dukhovni wrote: > Yes, that's the document. It still needs some work, but it can be > a stop-gap for the larger providers while they gear up to implement > DNSSEC (a few years work).
For large hosting providers this proposal makes sense, as I've noted. For the run-of-the-mill mail-server it won't really help that much in my opinion. See below. That said I've also noted my issues with DNSSEC in my GitHub issue. > >> And I also think I've broken your proposal in this GitHub issue: >> https://github.com/mrisher/smtp-sts/issues/1 > > No. Neither DEEP nor TACK can protect MTA-to-MTA SMTP. The reason > is MX indirection. DEEP and TACK pin server properties, not domain > properties. The MITM will just forge the MX RRset and bypass DEEP > and TACK. In any case, there are domains to which I send email > very infrequently, but still want the transport to be secure, none > of DEEP, TACK or STS address that. I'm not saying that TACK is the only and ultimate way to go. It served as an example in this case. The major problem I see with DNS is that a lot of small mail-servers do not get a lot of attention, some of their operators might not even have direct DNS access (think semi-hosted setup where you have to either go through a web interface of your provider or actually write an e-mail. Another case is where the Postmaster has no real influence on DNS record because of company/university/whatever bureaucracy). I know you heavily support DANE and I do like DANE in general but see major problems in DNSSEC still (not only deployment). Aaron
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
