On Wednesday, 11 May 2005 at 22:02, David Champion wrote:
>
> Thanks for your comments, Brendan. To address what you've said already:
>
>
> * On 2005.05.11, in <20050512015051.GA412@xxxxxxxxxxxxxx>,
> * "Brendan Cully" <brendan@xxxxxxxxxx> wrote:
> >
> > I believe this is the format defined in RFC 2595.
>
> I see something similar, but not that exactly. I suspect/hope that
> it's in an RFC, but it doesn't appear to be 2595. I'll keep looking --
> perhaps it's in one of the more directly SASL-related RFCs, and 2595
> uses what it has based on that precedent.
Note that the exchange gets transformed by the SASL IMAP
profile. That's where the base 64 encoding happens, for instance.
> I might be missing something -- I haven't been able to use/look at
> SASL very extensively -- but I thought it was necessary to support
> SASL explicitly on both sides. If that's so, then to the best of my
> knowledge I'm not looking at a SASL-capable server.
I'm not sure what you mean, but SASL support is indicated by
AUTHENTICATE=foo fields in the IMAP capability list. If a server
advertises those, it is supposed to be compatible with any SASL client
that shares the same mechanisms. Mirapoint probably is. I wonder
whether UW already does support PLAIN, now that I think about it.
> It's likely not broadly useful, true. But when you need authuser,
> you need it in a mail client, and mutt is the choice of many mail
> administrators.
I think that's true. That's why I'd like to see a SASL patch :)
That would make it more general anyway - SASL should support authuser
for GSSAPI and DIGEST-MD5 as well as PLAIN.
> ago). More importantly I've never been able to fully build any version
> of SASL on any version of Solaris, and I've heard vaguely of other
> people's portability problems with it, so I don't feel very alone. But
> I might not have been batting it with a heavy enough brick, since I've
> never *needed* to use it. I have a feeling it's not code, it's just
> auto{make,conf} configuration madness.
I'm pretty sure it's surmountable. For one thing, blastwave packages
it. I haven't looked at the package though.
> I suspect that one day I'll need to stop worrying and love SASL anyway.
> I just don't like to see this difficulty as a requirement for my mutt
> build, when I don't otherwise have any need of SASL at all and a small
> amount of existing code can dodge the dependency.
Fair enough. But the tentacles of the SASL library are spreading, and
honestly I think that's a good thing. More applications should have
decent authentication primitives, and libsasl's a whole lot easier to
use than the kerberos libraries. Maybe I'll get around to the trivial
$imap_authuser patch myself in a couple of weeks, if you don't feel
like it. But, if it's any incentive, I'll commit a SASL version before
1.6 :)
After all, it should be pretty trivial.
Attachment:
pgpJbtKheqsTB.pgp
Description: PGP signature