Re: [Exim] TLS, AUTH and relaying (testing TLS support)

Top Page
Delete this message
Reply to this message
Author: Phil Pennock
Date:  
To: exim-users
Subject: Re: [Exim] TLS, AUTH and relaying (testing TLS support)
On 2000-10-11 at 14:17 +0100, Nigel Metheringham gifted us with:
> There are, from memory, several things that you might wish to use to 
> allow/reject messages:-
>     - TSL settings, including TLS certificates
>     - IP addresses, networks/netmasks of connecting host
>     - host/domainname of connecting host
>     - DNS registration or not (+allow_unknown)
>     - RBL information
>     - SMTP authentication
>     - sender envelope address
>     - recipient envelope address (ie allow mail to postmaster)

>
> How on earth we can extend the configuration to sanely allow any
> combination of these without coming up with a scheme thats harder to
> read and understand than a sendmail.cf file is rather difficult :-(


Extend host/domain lists. Have a new prefix. Be more verbose in doing
so - are there problems with using [...] or {...} as a prefix?

host_accept_relay = {AUTH}* : localhost: !{DNS}* : \
            net24-dbm;/networks.db


Multiple prefixes indicate boolean AND. The list syntax already
provides OR. So to allow any host, if authenticated and using TLS, to
allow localhost, or to allow an authenticated connection from
192.168.42.0/24, and reject otherwise,

host_accept_relay = localhost : {AUTH}{TLS}* : \
        {AUTH}192.168.42.0/24 : ! *


There are likely to be a host of problems with this ... and is probably
cleanly do-able with ${auth: ... } or something.

Disclaimer: I haven't played with the TLS stuff at all. But this is an
idea for an extensible syntax could integrate reasonably well. Probably
better not to use {} as I've done - are square brackets available? Or
angled brackets <> ?
--
Civilisation: where they cut down the trees and name streets after them.