May 24, 2024 9:42 AM, "Omar Polo" <op@omarpolo.com> wrote:

> On 2024/05/23 21:55:50 +0000, gilles@poolp.org wrote:
> 
>> Hello,
>> 
>> Just a mail to propose an idea that I discussed with op@ in private.
>> 
>> In smtpd, there are two codepaths for authentication:
>> 
>> 1- if no table was provided, smtpd relies on bsd_auth(3)
>> 
>> 2- if a table is provided, it performs a K_CREDENTIALS lookup which,
>> given a username as a key, looks up the crypt(3)-ed password that
>> is then compared to the one that the user provided.
>> 
>> When you provide a table to the auth keyword, ie:
>> 
>> listen on all [...] auth <foobar>
>> 
>> Regardless of the backend used by <foobar> you take the second path,
>> which is great because any backend that supports key-value lookup is
>> usable as an authentication backend in smtpd: inline, file, db, ...
>> 
>> Problem is that some backends do not expect to be queried this way.
>> 
>> For example, OpenLDAP and OpenBSD's ldapd have an existing attribute
>> userPassword which is mandatory but which we can't use because it is
>> not in the format we expect and not meant to be fed to crypt(3) like
>> we do for all other table backends. In such cases, we'd rather let a
>> table backend do the validation and tell us if it succeeded.
>> 
>> This diff introduces a new lookup service K_AUTH which is only meant
>> to be used by table backends that need custom auth validation. If we
>> authenticate against a table that supports K_AUTH, then instead of a
>> K_CREDENTIALS lookup we forward the username:password so the backend
>> can tell us if authentication succeeded or not.
>> 
>> ok ?
> 
> after sleeping on this I think that maybe we should document this under
> smtpd-tables.7 rather than table.5 because this is not about the format
> of the data, but rather a special mechanism only for proc tables.
> 

You're right and I found it annoying that auth is described before credentials
when most people will use credentials so I'm all for moving the blurb.


> but in any case, it reads fine and I've been surprised by how simple it
> is!
> 
> ok op@
> 
> nit below
> 
>> [...]
>> --- table.5 2 May 2024 18:14:33 -0000 1.14
>> +++ table.5 23 May 2024 21:07:15 -0000
>> @@ -113,6 +113,19 @@ Here, the user is allowed to send mail f
>> .Bd -unfilled -offset indent
>> .Ic listen on Ar interface Cm auth Oo Ar ... Oc Cm senders Pf < Ar table Ns >
>> .Ed
>> +.Ss Authentication tables
>> +In most cases,
>> +authentication is best served by a credentials table which provide information that
> 
> nit: this is longer than 80 chars :p
> 
> (and IIRC the mantra is "new sentence, new line", so no need to break the
> line after a comma.)
> 

I'll update the diff later today to incorporate in smtpd-tables.7 and fix these.


>> +.Nm smtpd 8
>> +can use to validate itself using
>> +.Nm bsd_auth 3
>> +or
>> +.Nm crypt 3 .
>> +.Pp
>> +In some cases,
>> +this is not desireable and the validation needs to be offloaded.
>> +The authentication tables support doing a check on a username and password,
>> +returning success or failure based on custom logic.
>> .Ss Domain tables
>> Domain tables are simple lists of domains or hosts.
>> .Bd -unfilled -offset indent