James Cloos <[email protected]> wrote: > A point of discussion is what, if anything, the receiving MTA should do > dane-wise with and cert offered by the sending MTA.
I think this might be interesting to pursue but it could be a deep rat hole. I prefer to get server authentication complete first. I believe it would not be feasible to tie the sending host identity to the sending mail domain. That would repeat the error made by SPF. So the only benefit we can get is authenticating the sending host; some other mechanism (i.e. DKIM) is necessary for higher-level identities. What benefit would client authentication give you? At the moment we usually assume that bidirectional TCP is good enough for us to believe the client IP address; this is evidently a bit shaky given the lack of routing security, but even if we had secure routing we could still be open to spoofing attacks from sufficiently well-placed on-path attackers. For intra-domain mail, client authentication is useful for gaining permission to relay arbitrary mail. It's perfectly sensible to use client certificates for this, probably validated using a private CA. If DANE takes off it might be preferable to use the DNS instead. For inter-domain mail the client IP address is looked up in reputation services and used for tracing and logging. You might care about making this harder to spoof, but it's fairly marginal I think. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
