Re: [Evolution-hackers] [Fwd: Re: [evolution-patches] [PATCH] IMAP preauth and subcommand connection.]

[David Woodhouse <dwmw2 infradead org>]

On Mon, 2003-07-21 at 21:59, Not Zed wrote:
> I see a couple of possibilities for it that he might accept, that i've
> listed below.  Perhaps this can be discussed and something acceptable
> worked out.  I think the feature is useful and is a security
> enhancement (for server maintainers, since they don't need to run an
> imap port).

It's also just occurred to me that this gives you transparent SOCKS
support too -- just use a socksified netcat as your command...

>  *- could add another 'server type' to the server type thing, with a new
> pseudo-url-protocol, implemented using the same imap objects (you just
> need to add another provider in the imap module init).
> 
> e.g. IMAP via command, "imapc://"

I prefer your latter option over this, but I'll implement this one if
it's preferred -- I'm more interested in getting the functionality
_available_ than arguing over UI details.

>  *- change the 'user secure connection (ssl): ...' line of that page to be
> something like
> 
> 'Connect using' [remote host]
>                 [always ssl]
>                 [ssl when possible]
>                 [command]     [ command entry box shows up ]
> 
> This is probably simpler to code, doesn't add another server type,

Seems more intuitive to me than a separate server type too -- after all,
it's _not_ a different type of server, it's just a different way of
connecting -- this suggestion seems far more 'right'.


>  but it will end up with a redundant host and username entry.

Well, they're not really redundant. They're made available to the
command we run in environment variables -- and the default command is
something like 'ssh -C -l $URLUSER $URLHOST exec /usr/sbin/imapd' which
uses them appropriately.

Of course you _could_ specify a command which doesn't use them; that's
sort of the point in it being a _custom_ command -- but that's not
really _expected_ behaviour.

>   And it will look a little funny if ssl isn't compiled in.

Why so? Doesn't the choice get reduced to...
  'Connect using' [remote host]
                  [command]    
... in that case? 

>  *-  Actually, the 'connect using' line could perhaps be above the
> host/username fields, and change them according to its setting.  Or the
> host/username fields could be available as '%h' '%u' in the command
> string ...

Variation on the latter. By doing it as environment variables we simply
the exec code and don't have to muck about with string substitution for
ourselves.

> (it still has the url problem i guess - i'm not sure how the rest of
> the imap and mailer code would handle not having a hostname on a 'remote'
> server).

Given that the host and username aren't expected to be redundant, these
aren't actually problems, right?

> This last is probably the cleanest, ui-wise.

I think so too. I'm happy to go an implement this if it's likely to be
acceptable.

-- 
dwmw2