B. Cook wrote:
> Is this possible?
> 
> This is what I currently have..
> 
> 336 begin authenticators
> 337
> 338 login:
> 339   driver = dovecot
> 340   public_name = LOGIN
> 341   server_socket = /var/run/dovecot/auth-client
> 342 # setting server_set_id might break several headers in mails sent by 
> authenticated smtp. So be careful.
> 343   server_set_id = $1
> 344
> 345 plain:
> 346   driver = dovecot
> 347   public_name = PLAIN
> 348   server_socket = /var/run/dovecot/auth-client
> 349   server_set_id = $1
> 350
> 
> 
> and I would like to add additional options like if they are coming from 
> 127.0.0.1..
> 
> login:
>    driver = dovecot
>    public_name = LOGIN
>    server_socket = /var/run/dovecot/auth-client
>    server_set_id = [email protected]
> 
> plain:
>    driver = dovecot
>    public_name = PLAIN
>    server_socket = /var/run/dovecot/auth-client
>    server_set_id = [email protected]
> 
> 
> 
> Is that possible?

Yes. In more that one manner.

>  how would I do that?
> 
> Thanks in advance.
> 
> 

Depends to some extent as to 'how' they are 'on' localhost/127.0.0.1

- If users with login and shell, they could, if permitted, invoke the binary 
directly, thereby bypassing Exim's authentication. It is ass u me 'ed that they 
have passed rigorous login:auth already - which may be a lie for web forms and 
the like.

;-)

- For 'virtual' users who do NOT have shell logins, a webmail such as 'Prayer' 
which can itself invoke the binary as the user it is being operated as, may 
also 
be able to bypass Exim's authentication.

- A webmail such as that contained in Webmin/Usermin may do *either*, eg: a 
full-handshake local OR remote smtp session OR a call to the local binary, 
depending on how it is configured - IOW you get to choose.

- As reads 'webmail' can also read non-web server-resident mailers.

So .. before making your authenticator(s) more complex, the first question is 
whether it will be utilized [always | sometimes | never], and how or IF you 
plan 
to enforce <whichever>.

- at which point IF 'local' also means you have some control over the 
configuration of the clients, I would be tempted to use a different *port* as 
well as IP, partly for the follow-on ease of comparing on the inoming-attached 
$interface_port' variable AND'ed with the 'authenticated', and perhaps even 
'$protocol'.

One could also bind a listener to, for example, an 'internal' IP on a 
non-public 
NIC such as 192.168.0.(n) [1] instead of 'localhost', as that helps avoid some 
of the legion of 'special case' things that apply to 'localhost'.

FWIW - Exim knows, will log if asked to, and can respond to filters on, 'most 
things that can be known' about *any* arrival, authenticating or otherwise.


Ex;

====

2009-05-28 03:51:12 [24288] SMTP connection from [202.82.70.252]:49258 
I=[203.194.153.81]:587 (TCP/IP connection count = 1)

2009-05-28 03:51:13 [39492] no host name found for IP address 202.82.70.252

2009-05-28 03:51:13 [39492] H=202.82.70.252 (<redacted>.local) 
[202.82.70.252]:49258 I=[203.194.153.81]:587 Warning: H1   202.82.70.252 
202.82.70.252 submission client arriving on port 587 with smtp

2009-05-28 03:51:13 [39492] H=202.82.70.252 (<redacted>.local) 
[202.82.70.252]:49258 I=[203.194.153.81]:587 Warning: R0   202.82.70.252 
202.82.70.252 is authenticated using esmtpsa

====

Lots of options... *providing* you can enforce an 'smtp-session', not let a 
directly-invoked binary slip under the fence.

HTH,


Bill


[1] May be an alias. Actual cable optional. So, too a physical NIC.



-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to