Re: An alternative to Cyrus SASL

> > That would require the SASL daemon to understand SMTP. The daemon
>
>Do not take me too literally.

Sometimes you expect people to read your words _very_ literally :o)

I read the Plan 9 auth paper. In an example given a POP server wants
to start a conversation with the client. Factotum tells the server to
start with "+OK POP3 cxhxaxlxlxexnxgxe". The POP server would pass
that verbatim to the client and pass the client response back to
Factotum. I just combined your idea of transparent proxy with this
example.

Now I know better.

>The SASL API is way too complicated for the trivial needs of Postfix.

Whenever you have time to sit down and go through the whole process,
you will find that you are going to need the five steps I outlined
earlier:

>1) initialize
>2) get a list of mechanisms
>3) start the mechanism that client selected
>4) pass protocol data to/from client until success or error
>5) clean up
>With the different mechanisms there are variable number of rounds at #4.

That is the Cyrus|GNU SASL API. I don't think you can do it any simpler.

What you can do is simplify the argument lists a bit. The callbacks
are a real hassle, but there won't be any since the SASLD would be
responsible to look up the secrets in some datastore.

I am eager to see what you have in mind. I have given this matter a
lot of thought lately. Maybe I can give some constructive feedback. I
hope I am not too set in the current API frameset, though.
--
Cheers
Petri

GSM: +358 400 505 939