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: Joshua Cranmer <Pidgeot18@verizon.net>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 487C1289.7000902@verizon.net permalink / raw / eml / mbox
First off, thanks to those of you who provided resources in my last 
thread; I have found them of use, although the wiki looks like it could 
use some work.

I still have more questions related to the protocol, though:

1. Is it required that there be a namespace consisting of ""? If not, 
then what are the implications for INBOX?

2. The explanation "CHECK" says
>  The CHECK command requests a checkpoint of the currently selected
>  mailbox.  A checkpoint refers to any implementation-dependent
>  housekeeping associated with the mailbox (e.g., resolving the
>  server's in-memory state of the mailbox with the state on its disk)
>  that is not normally executed as part of each command.  A checkpoint
>  MAY take a non-instantaneous amount of real time to complete.  If a
>  server implementation has no such housekeeping considerations, CHECK
>  is equivalent to NOOP.

Which, if any, other commands imply a housekeeping update? I presume 
CLOSE and LOGOUT would have similar semantics, and another developer 
suggested that EXPUNGE might.
Also, which data need not be saved?

3. For testing purposes, would it be better to:
  a) Return PREAUTH in the initial response
  b) Fail to support LOGINDISABLED as a capability without using TLS
  c) Blithely return OK to all AUTHENTICATE requests (again without TLS)

4. How supported and/or stable is the EAI-IMAP-UTF8 spec? Folding in 
some of my questions on this spec:
  a) How does this interoperate with legacy modified UTF-7 mailbox names?
  b) If a server treats mailbox names as case-insensitive, should it 
treat the UTF-8 names as case-insensitive only with respect to ASCII, 
similar to how the UTF-7 version treated it?
  c) What is the rational behind forbidding UTF-8 non-ASCII characters 
in "" strings?
  d) Are literals assumed to be UTF-8 if not otherwise specified? (e.g.,
C: 1 SELECT {6+}
C: mail?
should be considered a legal mailbox of the name "mail?" and not 
semantically invalid)

5. (Not related to RFCs or draft RFCs) Is there a public IMAP server 
containing the imap-protocol archives as a mailbox or namespace that I 
can use for searching? Mailman does not make using list archives easy...

Once again, thanks in advance for your responses.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Reply
E-mail headers
From: markrcrispin@live.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: BLU126-W35254E159F43B4B4DB4CAFB88C0@phx.gbl permalink / raw / eml / mbox
> 1. Is it required that there be a namespace consisting of ""?

No, although not having it is somewhat pointless.

> If not,
> then what are the implications for INBOX?

INBOX is not part of any namespace.  It is a special reserved name

> Which, if any, other commands imply a housekeeping update? I presume
> CLOSE and LOGOUT would have similar semantics, and another developer
> suggested that EXPUNGE might.

SELECT and EXAMINE would as well.

> Also, which data need not be saved?

Data should always be saved.  The whole point of CHECK is to assist mailbox formats such as the traditional UNIX mbox format in which saving a flag state involves a significant file rewrite.  CHECK should be equivalent to NOOP with superior mail stores.

> 3. For testing purposes, would it be better to:
> a) Return PREAUTH in the initial response
> b) Fail to support LOGINDISABLED as a capability without using TLS
> c) Blithely return OK to all AUTHENTICATE requests (again without TLS)

That's up to you, but relatively few IMAP clients support PREAUTH (it's used primarily with UW's rsh/ssh IMAP functionality).

> 4. How supported and/or stable is the EAI-IMAP-UTF8 spec?

IMHO, it is too knew to rely upon

> a) How does this interoperate with legacy modified UTF-7 mailbox names?

A server that implements EAI-IMAP-UTF8 is responsible for doing all the necessary conversions, for the benefit of a client that does not implement it.  That's a pretty heavy burden on a server.

> b) If a server treats mailbox names as case-insensitive, should it
> treat the UTF-8 names as case-insensitive only with respect to ASCII,
> similar to how the UTF-7 version treated it?

That's up to the server.

However, IMHO, a server that offers case-insensitive mailbox names and UTF-8 mailbox names should be case-insensitive for all of Unicode.  Note that a good IMAP server needs to suppose i;unicode-casemap, so that level of case-independent framework should already exist.

> c) What is the rational behind forbidding UTF-8 non-ASCII characters
> in "" strings?

Mostly legacy reasons, including the need to exterminate the unofficial ISO 8859-1 and Shift-JIS strings.  Quoted strings are of relatively little value except for short ASCII strings.

> d) Are literals assumed to be UTF-8 if not otherwise specified? (e.g.,
> C: 1 SELECT {6+}
> C: mail?
> should be considered a legal mailbox of the name "mail?" and not
> semantically invalid)

Literals have an undefined charset unless something defines it.  This is because there are legacy servers that transmit ISO 8859-1 and Shift-JIS.  There is a 12 year effort to exterminate all such usage.

-- Mark --

_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008
Reply