Re: I want to add non-RFC passwd to pop and imap

[Alain Magloire]

> 
> 
> --mP3DRpeJDSE+ciuQ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> Reading the RFCs, they are riddled with references to browsers and
> users, seemingly without awareness that URLs are generally useable
> for descriptions of how to access resources. Passwords were
> disallowed for security reasons that do not exist in many applications.
> 
> Example, mutt's configuration file:
> 
> set spoolfile=imap://address@hidden
> set imap_pass=XXX
> 
> The security advantage is....?

8-), None.
As you pointed out, the RFCs were more concern by the use
of URLs containing passwd in HTML pages or documents that
are readable by all.

> 
> It *should* allow the password as in the other URLs, ftp, http,
> etc., now you have to invent another syntax for fully specifying
> the resource, and note that Mutt's mechanism is not general
> enough, you have no way to specify which imap url the password
> is associated with.

Unfortunately, the rationale and the wording of the RFCs
were very clear.  But I certainly understand the point you
are making and feel the same way.  So if you are proposing
to allow in the URL passwd as an extension, I'm all for it
if it does not break severly the current semantics in the
RFCs.
  

> 
> With sieve, I can't prompt the user for a password, it's for
> unattended operation. I could invent a configuration file
> that mapped passwords to URLs, for a hefty complexity and
> flexibility cost, and NO security gain. I don't see why.

> 
> Also, I looked into the docs, cut the URL example out, and
> compiled it. It doesn't do anything, sometime along the way
> the URL parsing code got pulled out of url.c, and copied into
> url_imap.c and url_pop.c. So, I pulled it back in, generalized
> it, added this API:

This was done IIRC, because according to the rfc's each scheme
is allowed to have whatever semantics after the "://", it does
not have to follow the wellknown:
 scheme :// user @ passwd / hostname : port / Query

Meaning it's not possible to come up with a general parsing algo
for all schemes.  But in the cases that we are interrested;
file:, pop:, imap:, mailto: They have enough similarities.

> 
> extern int  url_parse     __P ((url_t));
> 
> which is a little odd, but allows url_create() to do nothing (as
> it used to).
> 
> Now the imap and pop auth code, when looking for a password, looks
> to see if one was parsed from the url before prompting the user.
> I.e, backwards compatible.
> 
> I'm cleaning up the docs to match the new API before committing. But

Wow!

> is anybody going to be horrified? I REALLY think this is better than
> the alternatives, all involving an out-of-band configuration
> mechanism, mapping URLs to passwords.

It sounds cool me and have no objections, feel free to commit.

> 
> Sam
> 
> p.s. In the process, I added decoding of %xx sequences in urls.
> 

Nice.

> p.p.s. Attached is the url.c and imap_url.c for a more concrete
> example, url syntax is:

>         /* don't check return value, it's correctly coded, or it's not,
>            in which case we just skip the garbage, this is a decoder,
>            not an AI project */

8-) 8-)

--
alain