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 = $1@???
>
> plain:
> driver = dovecot
> public_name = PLAIN
> server_socket = /var/run/dovecot/auth-client
> server_set_id = $1@???
>
>
>
> 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.
