I've been trying to implement a more secure mail system,
by requiring the use of TLS when delivering to known domains.
Otherwise the setup seems to work nice, but the way Exim 4.24
handles certain TLS-related errors, seems to leave room for
certain improvements.
I have defined the following router just before the standard
dnslookup router:
secure_router:
driver = dnslookup
domains = ! +local_domains
condition =
${lookup{$domain}lsearch{/etc/exim/secure_domains}{yes} \
{${if match{$header_sensitivity:}{onfidential}
{yes}{no}}}}
transport = secure_smtp
no_more
As well as the corresponding transport:
secure_smtp:
driver = smtp
hosts_require_tls = *
tls_verify_certificates = /etc/exim/certs/
tls_certificate = /etc/exim/server.pem
As you can see from the condition in the router, I am also
experimenting with forcing a secure delivery if the email is
marked as confidential.
One particular problem arises if the remote server does not
support TLS, which results in Exim logging the following:
2003-11-27 15:44:33 1APMRW-0005ps-2v a TLS session is required for
mail.iki.fi [212.16.100.1], but the server did not offer TLS support
but that will not fail the delivery. Instead the delivery is
simply deferred and the delivery is retried per normal retry
rules (i.e. left in the mail queue until it bounces several
days later). In my opinion, failure to obtain a TLS session
for the delivery should bounce the message immediately, as
I don't think the problem would go away by trying again later.
Is there any easy way to handle these kinds of errors and
bouncing the message immediately? Or am I approaching this
problem ass-backward somehow?
(I have an ugly workaround with an additional router that
triggers on messages that are older than ten minutes and
matching the same conditions as the secure_router, whereby
the address is rewritten to a :fail:, but there *has* to
be better way to do it!)
--
Kai.Risku@??? GSM +358-40-767 8282
Oy Arrak Software Ab http://www.arrak.fi
