mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Timo Sirainen <tss@iki.fi>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 1245181628.21624.808.camel@timo-desktop permalink / raw / eml / mbox
Has anyone tested how well clients support catching capabilities after
login? I was planning on having Dovecot v2.0 send only very minimal
capabilities before login. The way it works is:

a) A new enough client that understands [CAPABILITY ..] :

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
1 login user pass
1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in

b) Client that doesn't understand [CAPABILITY ..]:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
1 capability
* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN
1 OK Capability completed.
2 login user pass
* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH
2 OK Logged in

Note that in b) case it's sending untagged CAPABILITY reply. This seems
to help a lot of clients.

The list of clients I've so far tested are:

 - Thunderbird v2.0 works
 - Alpine v2.0 works
 - Apple Mail works
 - Outlook 2003 works (tested by someone else than me)
 - Outlook Express works (tested by someone else than me)
 - Evolution ignores the updated capability.

The above list looks promising enough that I have some hope of being
able to actually do this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20090616/7544eeef/attachment.sig>
Reply
E-mail headers
From: mrc+uw@panda.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: alpine.OSX.2.00.0906161258240.4967@hsinghsing.panda.com permalink / raw / eml / mbox
On Tue, 16 Jun 2009, Timo Sirainen wrote:
> Has anyone tested how well clients support catching capabilities after
> login? I was planning on having Dovecot v2.0 send only very minimal
> capabilities before login.

I've done this for a long time with implicit capabilities.

> Note that in b) case it's sending untagged CAPABILITY reply. This seems
> to help a lot of clients.

I don't know if you care, but that would break an IMAP2 client. 
Hopefully, nobody is still using Pine 3.xx ...

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Reply
E-mail headers
From: brendan@kublai.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 20090616201719.GC90151@zanzibar.kublai.com permalink / raw / eml / mbox
On Tuesday, 16 June 2009 at 15:47, Timo Sirainen wrote:
> Has anyone tested how well clients support catching capabilities after
> login? I was planning on having Dovecot v2.0 send only very minimal
> capabilities before login. The way it works is:
> 
> a) A new enough client that understands [CAPABILITY ..] :
> 
> * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
> 1 login user pass
> 1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in
> 
> b) Client that doesn't understand [CAPABILITY ..]:
> 
> * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
> 1 capability
> * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN
> 1 OK Capability completed.
> 2 login user pass
> * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH
> 2 OK Logged in
> 
> Note that in b) case it's sending untagged CAPABILITY reply. This seems
> to help a lot of clients.
> 
> The list of clients I've so far tested are:
> 
>  - Thunderbird v2.0 works
>  - Alpine v2.0 works
>  - Apple Mail works
>  - Outlook 2003 works (tested by someone else than me)
>  - Outlook Express works (tested by someone else than me)
>  - Evolution ignores the updated capability.
> 
> The above list looks promising enough that I have some hope of being
> able to actually do this.

Mutt supports this too.
Reply
E-mail headers
From: mail@sabahattin-gucukoglu.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: B4D8E3E4-A3B1-4F02-B2EA-7C2BE5A38AC2@sabahattin-gucukoglu.com permalink / raw / eml / mbox
On 16 Jun 2009, at 20:47, Timo Sirainen wrote:
> Has anyone tested how well clients support catching capabilities after
> login? I was planning on having Dovecot v2.0 send only very minimal
> capabilities before login.

Is it standard behaviour to even expect clients to understand  
capabilities in untagged responses at all?  (Or has this just become  
unspoken convention somehow?)

Cheers,
Sabahattin
Reply
E-mail headers
From: tss@iki.fi
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 1245183163.21624.814.camel@timo-desktop permalink / raw / eml / mbox
On Tue, 2009-06-16 at 13:00 -0700, Mark Crispin wrote:
> On Tue, 16 Jun 2009, Timo Sirainen wrote:
> > Has anyone tested how well clients support catching capabilities after
> > login? I was planning on having Dovecot v2.0 send only very minimal
> > capabilities before login.
> 
> I've done this for a long time with implicit capabilities.

You mean with those [CAPABILITY ..] response codes? But do you also
return reduced capabilities when replying to a CAPABILITY command before
login? That's the main change I'm hoping to make, because in some setups
the list of capabilities isn't known before knowing the username.

> > Note that in b) case it's sending untagged CAPABILITY reply. This seems
> > to help a lot of clients.
> 
> I don't know if you care, but that would break an IMAP2 client. 
> Hopefully, nobody is still using Pine 3.xx ...

I'd rather break Pine 3.xx than Thunderbird, Outlook and OE. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20090616/b340482b/attachment.sig>
Reply
E-mail headers
From: tss@iki.fi
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 1245255382.21624.854.camel@timo-desktop permalink / raw / eml / mbox
On Wed, 2009-06-17 at 09:30 +0100, Sabahattin Gucukoglu wrote:
> On 16 Jun 2009, at 20:47, Timo Sirainen wrote:
> > Has anyone tested how well clients support catching capabilities after
> > login? I was planning on having Dovecot v2.0 send only very minimal
> > capabilities before login.
> 
> Is it standard behaviour to even expect clients to understand  
> capabilities in untagged responses at all?  (Or has this just become  
> unspoken convention somehow?)

Well, RFC 3501 mentions automatically sent capabilities in a few places,
like:

> A server MAY send capabilities automatically, by using the
>       CAPABILITY response code in the initial PREAUTH or OK responses,
>       and by sending an updated CAPABILITY response code in the tagged
>       OK response as part of a successful authentication.  It is
>       unnecessary for a client to send a separate CAPABILITY command if
>       it recognizes these automatic capabilities.

So I guess it's preferred to send CAPABILITY response code in response
codes instead of untagged CAPABILITY, and this is also what Dovecot does
as long as client doesn't ignore them by requesting the CAPABILITY
again. The untagged CAPABILITY sending is only a workaround to many
commonly used clients.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20090617/98e1bf7c/attachment.sig>
Reply
E-mail headers
From: mrc+uw@Panda.COM
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: alpine.OSX.2.00.0906161341350.4967@hsinghsing.panda.com permalink / raw / eml / mbox
On Tue, 16 Jun 2009, Timo Sirainen wrote:
>> I've done this for a long time with implicit capabilities.
> You mean with those [CAPABILITY ..] response codes?

Yes.

> But do you also
> return reduced capabilities when replying to a CAPABILITY command before
> login?

No.

> That's the main change I'm hoping to make, because in some setups
> the list of capabilities isn't known before knowing the username.

I see no problem with doing that.  It has always been intended that 
capabilities can change at authentication (and STARTTLS) time.

>>> Note that in b) case it's sending untagged CAPABILITY reply. This seems
>>> to help a lot of clients.
>> I don't know if you care, but that would break an IMAP2 client.
>> Hopefully, nobody is still using Pine 3.xx ...
> I'd rather break Pine 3.xx than Thunderbird, Outlook and OE. :)

Indeed.  However, it's not clear that there won't be other clients that 
will toss their cookies at receiving an unsolicited CAPABILITY response; 
and as I said IMAP2 clients will definitely do so.  That's why the 
CAPABILITY response code exists.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Reply
E-mail headers
From: mrc+uw@panda.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: alpine.OSX.2.00.0906170920380.6922@hsinghsing.panda.com permalink / raw / eml / mbox
On Wed, 17 Jun 2009, Timo Sirainen wrote:
> Well, RFC 3501 mentions automatically sent capabilities in a few places,
> like:
>> A server MAY send capabilities automatically, by using the
>>       CAPABILITY response code in the initial PREAUTH or OK responses,
>>       and by sending an updated CAPABILITY response code in the tagged
>>       OK response as part of a successful authentication.  It is
>>       unnecessary for a client to send a separate CAPABILITY command if
>>       it recognizes these automatic capabilities.

Note that it says "CAPABILITY response code", not "untagged CAPABILITY 
response"

> So I guess it's preferred to send CAPABILITY response code in response
> codes instead of untagged CAPABILITY, and this is also what Dovecot does
> as long as client doesn't ignore them by requesting the CAPABILITY
> again. The untagged CAPABILITY sending is only a workaround to many
> commonly used clients.

UW IMAP once sent automatic untagged CAPABILITY responses, and I had 
complaints of numerous clients puking over it.  Some were IMAP2 (and thus 
this was expected), but others were supposedly IMAP4 capable.

It was for this reason that the CAPABILITY response code came into being.

This was 10 or so years ago.  The clients which had problems may be 
extinct by now.

RFC 3501 requires that a client get new capabilities after STARTTLS (page 
27), and strongly indicates that also be done after AUTHENTICATE (page 29) 
and LOGIN (page 31).  SASL requires that a client get new capabilities 
after an AUTHENTICATE command that negotiates a security layer.

What this all means:
  1) The client must acquire capabilities at:
     . session start
     . after the tagged OK for a STARTTLS command
     . after the tagged OK for an AUTHENTICATE command that negotiates a
       security layer
     . at or after the tagged OK for an AUTHENTICATE command that does not
       negotiate a security layer
     . at or after the tagged OK for a LOGIN command
  2) After STARTTLS, the client MUST issue a CAPABILITY command.  No form
     of automatic capabilities can be used.
  3) After AUTHENTICATE that negotiates a security layer, the client MUST
     issue a CAPABILITY command.  No form of automatic capabilities can be
     used.
  4) If the server includes a CAPABILITY response code in the initial
     untagged OK or PREAUTH greeting, or in the tagged OK from an
     AUTHENTICATE command (that does NOT negotiate a security layer) or
     LOGIN command, the client can use those capabilities and not need to
     issue a CAPABILITY command.

Put another way, any client that benefits from the workaround is broken.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Reply
E-mail headers
From: tss@iki.fi
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 1245257710.21624.873.camel@timo-desktop permalink / raw / eml / mbox
On Wed, 2009-06-17 at 09:36 -0700, Mark Crispin wrote:
>   2) After STARTTLS, the client MUST issue a CAPABILITY command.  No form
>      of automatic capabilities can be used.

Oh, this was something I had forgotten. I'll modify my workaround
slightly then:

If client issues CAPABILITY command before STARTTLS (i.e. ignored the
CAPABILITY response code in the untagged greeting OK), send untagged
CAPABILITY reply before tagged LOGIN/AUTHENTICATE reply, instead of
using CAPABILITY response code in the tagged reply.

> Put another way, any client that benefits from the workaround is broken.

Sure, but there's no way to get Outlook/OE fixed. At least Thunderbird
v3.0 will understand CAPABILITY response codes.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20090617/e9ba9ba5/attachment.sig>
Reply