Re: Enhancement of mailer_t delivery API.

[Sam Roberts]

Houf. I'm getting lost in the thread...

Quoting Alain Magloire <address@hidden>, who wrote:
> 1) Make this legal syntax in url_parse:
> 
>  pop://alain:secret;address@hidden

Ok!

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

Agreed that this is the right way.

-- I'm getting confused, I think we are wandering around saying the
 same stuff, basically, is that your impression? --

Q1: Do we need a .tickets for security?

A1: No.

Either the passwords are in ~/.sieve, and the script needs to
be readable only by the user and the sieve script, or...

the passwords are in ~/.tickets, and ~/.tickets needs to be
readable only by the user and the sieve script...

Same security properties.

Its only different when I mail my script to bug-mailutils to ask why it isn't
working, and I have to delete the passwords, which is annoying.

Q2: Do we need .tickets then?

A2: Yes!

It is useful for ticket management. I can configure /usr/bin/mail,
my sieve scripts, my guile script run from cron, etc., to all use
it for tickets. It can also (see previous email) implement a more
general registry, i.e. "all pop passwords are xxx, all passwords
in gnu domain are yyy, all imap uses this TLS cert&key". Useful.

Note: Owner and all

If a ticket is created from a ticket file, then as an implementation
detail it must be known in it's callback what url it is supposed
to be retrieving ticket info for. If the owner can't be crawled
back up, then that info, the url perhaps must be passed into the
callback.

Q3: What will sieve use.

A3: Whichever mechanism the user of sieve wants...

Script I run from a cron job, by hand, etc, why not specify the
full url w/password in the script? Handy during development, handy
for putting together quick scripts.

When I decide to put my passwds in .tickets, I need to tell
the script to use them. I see a few ways, all of which should be
supported:

- implicit: there's a ~/.ticket, so use it
- explicit: -t <ticket file> cmd line option, ENV var, etc.
- specified in script: require ["ticket"]; ticket "~/.mytick";

Gotta get some coffee.... go to work...

Sam

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