------- 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 <tom@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|bug |wishlist
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #3 from Tom Kistner <tom@???> 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
