Re: Enhancement of mailer_t delivery API.

[Alain Magloire]

Bonjour

> 
> Yes, I read them as alternate mechanisms. I don't remember, wasn't
> something like
> 
> pop://alain;AUTH=+APOP,address@hidden
> 
> allowed? We could extend it again... I don't think "," is going
> to be part of an auth mechanism. Ugly....

Indeed, it is ugly, 8)
better stick with the old fashion way

 pop://alain:secret;address@hidden

and beat url_parse() into submission in parsing this correctly.

Let me recap the problem.  We have authentication objects
that implement a certain type of protocol, SASL, APOP,
User/passwd etc ..  Those objects uses ticket_t/ticket_pop()
as a callback to get external information.  When there
is no callback set on the authority, it falls back
in to prompting on the console to get the info
i.e passwd, user name..

This can be annoying if you use this mechanism via
script(sieve comes to mind) where mailbox_t are create
and open on the fly.  Solution:

(1) setting a special callback/ticket_t that will
    get the info from a file or another way.

(2) Another way, would be to mangle the URL to pass much more
    information say something like
 pop://alain;AUTH=+APOP{/home/alain/address@hidden

    To say that the authentication is APOP and the secret is
    in /home/alain/.secret

I do not particularly like (2) because it imposes different
file parsing problems(What's the format of .secret file),
Is it DB, GDBM, Ascii?  etc ...

With (1) the burden is not on the libmailbox to resolve the
issue.

> 
> Since I added passwd to the URL, I've been able to put
> it in the sieve script, so I've been ok.

Yes, but the problem is now security.  If you use things
like
  imap://sroberts:address@hidden/INBOX

The sieve script should be 600 at least.  Not what you
want.

> > 
> > I think, not sure, I was suppose to write a
> > ticket_file_create () or something that would read a file.
> 
> If I did it, I was supposed to do it in a generic way... but I didn't
> need it yet.

Sieve could implement a new capability say: "ticket" or "password_in"
lets try with ticket:

# !/usr/local/mailutils/bin/sieve
require ["ticket", "fileinto]

# Tell sieve on how to retrive my passwd.
#
ticket "/home/sroberts/.tickets"

# Send mailutils messages to my imap address@hidden
#
if header :is "Sender" "address@hidden"
{
  fileinto "imap://address@hidden";  # save in my imap account
}

[...]
> 
> What I want is:
> 
>   When you call sieve you can provide a "ticket file", or perhaps it
>   can use ~/.tickets if it exists.
> 
>   Sieve scripts will use either self-contained url's 
> (pop://user:address@hidden)
>   or ones missing auth info (imap://;auth=*host).
> 
>   When I the sieve engine passes my callback a string identifying a
>   mailbox, I don't have to know which case it is. I create the mailbox
>   from the string, magically the mailbox will use the ticket file
>   if it needs to...

Ok then in that case we do not need to mangle URL's to get this
behaviour ...  See above.

> 
> The above might work for me, but only if the authority checked the
> url, if it had all the auth info it needed it wouldn't call the ticket
> to ask for more. Also, somehow the ticket _pop callback needs
> to get more info, it needs to know the folder it is being asked to
> provide info for. Does the _ticket.owner point at the _authority? And
> does the _authority.owner point at the _folder? If so it can crawl
> back up and find that the folder is an imap folder on footsy.net,
> and get the appropriate stuff from ~/.tickets.

Ha! the owner, fortunately I'm doing the rewrite mailbox2 to clear the
confusion.  But unfortunately things are going at an impossible slow pace.

One of the confusion, is that you see owner as a parent/child relationship,
which it is not.  Call it "void * data", if you will, "owner" is just a
convenient place holder for the implementor of an object to hide some data.
The higher level objects: mailbox_t, ticket_t, authority_t
etc .. do not peek at the owner field nor dereference them, they are only use
for comparison when calling a xxx_destroy() to manage object lifecycle.

It was probably bad design decision on my part to mix this instead of having

xxx_set_data (void *);  // message_set_data (void *) // user pointer data.

Yes, .. I know it still not clear 8-)  I'll write a simple ticket_file_create()
later.

> What about if it needs an X.509 certificate (user...) and an
> RSA private key (pass...) for a TLS exchange? Can we shoe horn that
> in?

Yes.

> Ok, I send to much email, back to hacking.

Back to the ... muttons.