Re: [exim] restricting access to AUTH check based on user's …

Top Page
Delete this message
Reply to this message
Author: Dave Lugo
Date:  
To: exim-users
Subject: Re: [exim] restricting access to AUTH check based on user's IP
On Fri, 22 Apr 2005, Odhiambo G. Washington wrote:
>
> So if you define
>
> hostlist auth_relay_hosts = a.b.c.d/24
>
> and then in acl_smtp_auth you do:
>
> ####
> deny    hosts        = !+auth_relay_hosts
>         endpass
>         message      = You are not allowed to use SMTP AUTH from
>                        $sender_host_address
>         encrypted    = *

>
> accept
> #####
>
>
> Just an idea.....
>



Yes, that's the 'global' option. My current per-user iteration is
in the rcpt acl:

   accept  sender_domains = +accepted_here_domains
           authenticated  = *
           endpass
           message        = AUTH not allowed for $sender_address
           condition      = ${if exists \
                 {CFG_DIR/$sender_address_domain/$sender_address_local_part/auth-hosts}{1}{0}}
           hosts          = CFG_DIR/$sender_address_domain/$sender_address_local_part/auth-hosts



>
> How do you expect to get the "user" if you want to restrict AUTH
> by rDNS?
>



Exactly! Is there a way to know the username, and check it against
auth-hosts, *before* the password is checked? I need to do some more
reading of spec.txt. I suspect there is a way to do this, I just need
to spend some more time to figure it out. (and maybe get lucky enough
to get some hints from the mailing list)

I tried using acl_smtp_mailauth, but didn't have much luck (and so
reverted to using the rcpt acl while I do more research). My more
recent reading of spec.txt suggests that acl_smtp_auth (or the
authenticator itself) is likely the correct place to do what I'd
like.

Thanks,

Dave

-- 
--------------------------------------------------------
Dave Lugo   dlugo@???    LC Unit #260   TINLC
Have you hugged your firewall today?   No spam, thanks.
--------------------------------------------------------
Are you the police?  . . . .  No ma'am, we're sysadmins.