Re: Enhancement of mailer_t delivery API.

[Sam Roberts]

Quoting Alain Magloire <address@hidden>, who wrote:
> Sigh, it is not like I have a choice, in Ottawa.
> The choices of movies here are limited to American mainstream's.

Don't despair! Amelie may be at a main stream cinema!

> So I guess, it was deliberate.  When auth is specified
> passwd is disable? At least it seems this the way
> when reading the rfc.

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....

> > other was we have a way to parse URLs, but not write them
> > (with all the right encoding, etc). So the URLs need either
> > a create that takes all the parts and makes a url_t out
> > of them, or set functions, or... you get the idea.
> 
> 8-)
> Yes, but there was simply no needed for it i.e. I did not
> stumble on any thing that needed this  ... yet.
> But I did stumble in a lot of places where I needed it
> for address_t ;-)
> 
> > If that wasn't it, I'll search my mailbox.
> 
> No worries.
> I think it had something to do with sieve because
> you could not pass the passwd, and the mailbox would
> ask for it on the prompt, which was very annoying
> when doing a batch script.

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

> 
> The way to deal with this was to write a ticket_t object
> that would read a file and answers the ticket_pop() challenges.
> 
> 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.

> But you still did not tell me the format you wanted.

I think I said "later", because I didn't know what format...

imap://sroberts;address@hidden   secret
imap://address@hidden   secret
pop://address@hidden    secret2

Maybe with some kind of matching, so

gnu.org  passwd

would use passwd for all mechanisms in gnu.org.


pop:   joe

would use joe for all pop accounts, something...

It's at the elipsis that I decided not to hack something together
if it wouldn't make me happy.

> user: passwd
> ?
> 
> So you could do something like this:
> {
>   folder_t folder;
>   mailbox_t mbox;
>   authority_t auth;
>   ticket_t ticket;
> 
>   /* Parse ".secret" for "alain" to answer the ticket_pop() callbacks.  */
>   /* NOTE: The new code that sergey put in for popauth could get handy.  */
>   ticket_file_create (&ticket, "/home/user/.secrets", "alain");
> 
>   mailbox_create (&mbox, "imap://localhost");
>   mailbox_get_folder (mbox, &folder);
>   folder_get_authority (folder, &auth);
>   authority_set_ticket (auth, ticket);
> 
>   mailbox_open (mbox, MU_STREAM_READ);
>   /* You should not be prompt for passwd.  */
>   /* Since the ticket_pop() callbacks will be answered.  */
> 
>  ...
> }

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...


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.

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?

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

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)