------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=823 Tom Kistner <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|bug |wishlist Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #3 from Tom Kistner <[email protected]> 2009-03-20 16:18:22 --- (In reply to comment #2) > I'm not that worried about the security. The issue I'm trying to address is > the one where some other mail server comes up on my dangling IP and rejects my > mail, I'd be more worried if it accepts it :) In any case, when using host_require_tls and tls_verify_certificates, failure to negotiate a TLS session with a trusted cert will defer delivery. Which is what you want. > I do disagree with the closing of the bug though. If a transport is set up to > require authentication then that authentication should be used in the case of > callout verifies as well. I'll leave this decision up to you though, other > options imho is workarounds and does not address the real problem. I agree it is a missing feature. I'll re-open it and flag it as "wishlist". For your particular use case, using client authentication is the wrong way to go. You wish to verify the identity of a remote host. That should be done with TLS certs. A random host on a "dangling" dyndns record may just accept any username and pass that you send, then swallow your mail. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
