Re: [exim] requiring outbound AUTH at SMTP time

Pàgina inicial
Delete this message
Reply to this message
Autor: Rick Ennis
Data:  
A: exim-users
Assumpte: Re: [exim] requiring outbound AUTH at SMTP time
P.S. That's with Exim 4.43 on Fedora Core 3 but I could easily upgrade
if it facilitates a solution.

Thanks!


On Mon, 2005-03-28 at 15:48 -0500, Rick Ennis wrote:
> Specific situation... I have a user that wants guaranteed transport
> level encryption on all outbound messages. Using a regular 'dnslookup'
> router with an 'smtp' transport configured with:
>
>     hosts_require_tls = *
>     hosts_require_auth = +known_hosts

>
> would probably do it. If the message routes to a host that doesn't
> offer TLS or that we don't have AUTH credentials setup for the message
> bounces back to the local sending user.
>
> I'm wondering how I can make this a little more user friendly.
> Specifically I'd like to have the message rejected at SMTP time so the
> sender can tell when they hit 'Send' in their mail client instead of
> having to wait for a possible bounce. So I'm thinking this has to be in
> my check_rcpt_acl. And since it really hinges on which host the message
> gets routed *TO* I'd like to be able to compare that host with my list
> of +known_hosts.
>
> Question: When I run a router in verification mode via an ACL is there
> any way to get the name of the host(s) that it's going to pass on to the
> transport? Or is that host[list] not even setup by a router running in
> verification mode? Ideally I'm thinking something like
>
> deny verify = recipient
>      condition = ${if !match{+known_hosts}{$host}}

>
> though "match()" probably isn't the right condition since both of those
> arguments are potentially lists. But does that makes sense? Trying
> this in debug mode it *looks* like the host list is setup by the router
> in verification mode. But the $host variable definitely isn't set with
> it (nor does the manual suggest that it would be, I was just hoping).
> Is there another way for me to get at that info?
>
> Thanks,
> Rick
>
>