auth_t/ticket_t() was (Re: cmu-sieve:starting to work, patch about paths

[Alain Magloire]

Bonjour

  The passage on expanding ~ etc ... I'll get back to it later.

> p.s. Anybody have an example of how to make an auth object? I
> don't want a sieve daemon trying to prompt the console for
> a password for pop and imap boxes, and that this implementation
> of sieve will allow url specification of mailboxes since it's
> based on mailutils is one of the cooler features of it.

Few notes:

1-
  Don't register the pop_record and imap_record but rather just the
  path_record.  For example for the pop/imap daemon it may look cool
  to be able to do this:

For IMAP:

a00 SELECT imap://newhost.com:2000/INBOX

For POP:

USER imap://address@hidden
PASS xxxx

  Suprisingly they would have work by changing a few lines only,
  but it opens the door to all sort of abuse.
  So the pop3d and the imap4d  only register mbox/unix path_record.

  IMAP4 have an rfc extension call "referal", where the server part of
  the greeting redirect the client by sending a new hostname.  It is up to
  the mail client browser to do the right thing i.e the imap4d server is not
  the proxy.

2-
  I think you want ticket_t object not auth_t object, unfortunately
  they are not yet doc.  So let me explain briefly.  auth_t object
  are implementing protocols for authentication: MD5-AUTH, OTP, Kerberos,
  APOP, etc ..  The ticket_t object serves as the transaction object
  for the dialog/challenges.  So far I've only add a chance to code
  the USER/PASS auth_t object wich is the default created for you by
  the mailbox, this auth_t will call the ticket two times for the user
  and for the passwd.  So you if you do not want to be prompt you will
  have to override the ticket, here is and untested piece of code to
  illustrate:

struct prompt
{
  const char *user;
  const char *passwd;
  int state;
} my_user_passwd = { "sam", "passwd", 0} ;

/* The ticket pop. */
int user_passwd (ticket_t ticket, const char *value, char **ret_value)
{
        struct prompt  *up = ticket_get_owner(ticket);

        if (up->state == 0) {
            *ret_value = strdup (up->user);
             up->state = 1;
        } else {
            *ret_value = strdup (up->passwd);
            up->state = 0; /* We are done.  */
        }
        return (0);
}

/* Somewhere else in the code */
int main ()
{
       ticket_t ticket = NULL;
       mailbox_create (&mbox, "imap://....");
...

       ticket_create (&ticket, &my_user_passwd);
       ticket_set_pop(ticket, user_passwd, my_user_passwd);
       mailbox_set_ticket(mailbox, ticket);
...
       mailbox_open (mbox, ...);
....
       mailbox_close (mbox);
       mailbox_destroy (mbox);
       ticket_destroy (&ticket, &my_user_passwd);
}

  So in essence when you call mailbox_open () the mailbox_t object will:
  a- see if an object auth_t was already set and call it.
  b- try to look in the url to see if it can find the type of authentication
     if yes try to create it.
  c- if none of the above, create an user_passwd authentication and
     call the ticket_pop() function two times to get the info(user/passwd).
     If no ticket was set, create one that prompt from stdin.

3-  That should be enough to get you going if not, do it like this

  # /bin/echo "sam\npasswd" | sieve -f imap://localhost

8-) saves you some typing.

4- Unfortunately:
- there is only one auth_t protocol implemented, user/passwd, but
  in the future, we should have APOP, Kerberos etc ..
- It is still a little unclear how I pass some challenges, for
  example with APOP the key is pass on the greeting. 


> p.p.s. If anybody is interested in a snapshot, let me know, I hope
> to have the basic stuff working more robustly this weekend. At
> that point I'd be interested in comments on how to integrate this
> into a mail system. Right now it looks like:
> 
> $ ../sieve -h
> usage: sieve [-hnvcd] [-f mbox] script
> 
>    -h   print this helpful message and exit.
>    -n   no actions taken, implies -v.
>    -v   verbose, print actions to be taken.
>    -c   compile script but don't run it against an mbox.
>    -d   daemon mode, sieve mbox, then go into background and sieve.
>         new message as they are delivered to mbox.
>    -f   the mbox to sieve, defaults to the users spool file.

What!! no GNU long option  ... booo! booo! 8-)

> So you run the sucker against a mailbox, and it filters it, and the
> -d isn't implemented, but I was thinking that mailutil's observable
> interface would let me sit back and run the filter on new messages
> when I'm notified of new messages in the mailbox. Is that possible?

Everything is possible, but it that case no 8-).
What you are thinking is not implemented, you will have to do it
the hard way.  Some thing like:
{
  size_t total;
...
   for (;;) {
      sleep (seconds);
      if (!mailbox_isupdated (mbox)) {
        /* state change.  */
        mailbox_get_messages_count (mbox, total0);
        /* ... do stuff ... */
        if (total0 > total) { /* cool new mail.  */ 
        ...
          total = total0;
        }
      }
     /* nothing to do.  */
   }
}

I've resist so far, the urge to add a timer in the observer when
you register for MU_EVT_MESSAGE_ADD actions.  The idea was to have
a timer that would call a user function when you got new mail.

> This would let people like me, who's companies use lousy proprietary
> email packages but who grudingly give Unix users access to an
> IMAP port, the ability to filter their mail on arrival in the
> IMAP box to various local mailboxes, and to discard mail sent to
> "everyone" from marketing.
> 
> The other useful thing would be to have it be able to act as a local
> delivery agent, so it can accept mail from an MTA. Then I could
> maybe get the envelope to and from addresses from the MTA, which
> would be nice.

Interesting,  technically, when all the pieces of GNU mailutils are
in place/finish, yes.  And everything should work transparently.
Just by having this rule in sieve:
if header :is "Sender" "address@hidden"
{
        fileinto "imap://address@hidden";  #  personal mail redirect to home
} 

Your only problem would be to overide the ticket_t object to not
let the IMAP mailbox prompt you but rather get the passwd from
a file or something. (see above).

> 
> The spec talks about IMAP servers doing the filtering. This makes
> me think that another possibility is that if the MTA delivers

You mean MDA here.

> mail by appending it to an IMAP INBOX, that maybe the IMAP daemon
> could run the script on each new message it puts in the INBOX.
> This would maybe fit into the funky "notify" proposed extension
> to sieve.

I did not see this nowhere but that could be an extension of the
GNU imap4d. 

> Anyhow, food for thought.

Yep, that is good, it actually makes me see more clearly
the missing pieces in the mailbox library since this the
underlying engine. ... lot of work still.

Before getting on this project I did not thought that email could
be so complex.

--
alain