Re: [exim] perform different authentication depending on int…

Etusivu
Poista viesti
Vastaa
Lähettäjä: W B Hacker
Päiväys:  
Vastaanottaja: exim users
Aihe: Re: [exim] perform different authentication depending on interface?
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.