Bug#677826: TLS certificate not used for smarthost transport by default

[Ivan Shmakov]

>>>>> Ben Hutchings <ben at decadent.org.uk> writes:
>>>>> On Sun, 2012-06-17 at 09:05 +0200, Andreas Metzler wrote:

[…]

 >> The Debian configuration does the same, MAIN_TLS_* sets the changes
 >> the respective main TLS setting with no effect on the transport
 >> option.

 > OK, so how about adding new macros for this purpose?

	FWIW, in my configurations, I’ve complemented the already
	present REMOTE_SMTP_SMARTHOST*_TLS* macros with the following
	(as per the patch MIMEd; it’s for oldstable, but should apply
	cleanly to testing just as well):

REMOTE_SMTP_SMARTHOST_TLS_PRIVATEKEY
REMOTE_SMTP_SMARTHOST_TLS_CERTIFICATE
REMOTE_SMTP_SMARTHOST_TLS_VERIFY_CERTIFICATES
REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS

	It /may/ make sense to default them to the respective MAIN_TLS_
	ones in, say, conf.d/main/03_exim4-config_tlsoptions, but I’ve
	simply created a new main/00_local_tls_client (also MIMEd) just
	for them.

	This change allows for X.509-based authentication of smarthost
	“client” MTAs, which seems considerably more secure than the one
	based on IP address matching (IOW, MAIN_RELAY_NETS.)

[…]

-- 
FSF associate member #7257	http://sf-day.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-diff
Size: 863 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-exim4-maintainers/attachments/20130831/64ed29bf/attachment.diff>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-exim4-maintainers/attachments/20130831/64ed29bf/attachment.ksh>