Skip to content

Conversation

asutherland
Copy link
Contributor

We experience the following NAMESPACE command/response on a yahoo.co.jp
test account:

W6 NAMESPACE
* NAMESPACE (("" NIL)) NIL NIL
W6 OK NAMESPACE completed

The server greeting is:

* OK [CAPABILITY IMAP4rev1 ID NAMESPACE UIDPLUS LITERAL+ CHILDREN XAPPLEPUSHSERVICE AUTH=PLAIN AUTH=LOGIN] IMAP4rev1 imapgate-0.7.68_11_1.61475 imap515.mail.kks.yahoo.co.jp

The grammar in https://tools.ietf.org/html/rfc2342 says this is legal,
although I'm not seeing any examples or semantics:

Namespace = nil / "(" 1*( "(" string SP (<"> QUOTED_CHAR <"> /
nil) *(Namespace_Response_Extension) ")" ) ")"

I've opted to have the value pass through as null rather than normalizing it.
This is inconsistent with browserbox's current behaviour for LIST/LSUB in this
case (which I submitted the patches for). In those cases we normalize to '/',
which I didn't have a great reason for, but I also didn't know what else to do.
It may make sense to revisit that decision in the future. I've updated the
docs to reflect the current behaviour and that it may change.

In this case it seems like if we're reporting the namespace at all we might as
well report a falsey value so any consuming logic can know that the value is
not to be trusted and should use the delimiter reported by LIST/LSUB. I do
think we want to report the namespace since the root of "" is useful.

For reference, this is what LIST/LSUB looks like for the (freshly created)
account:

W4 LIST
* LIST (\\NoInferiors \\HasNoChildren) "/" "Bulk Mail"
* LIST (\\NoInferiors \\HasNoChildren) "/" "Draft"
* LIST (\\NoInferiors \\HasNoChildren) "/" "Inbox"
* LIST (\\NoInferiors \\HasNoChildren) "/" "Sent"
* LIST (\\NoInferiors \\HasNoChildren) "/" "Trash"
W4 OK LIST completed
W5 LSUB
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Bulk Mail"
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Draft"
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Inbox"
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Sent"
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Trash"
W5 OK LSUB completed

We experience the following NAMESPACE command/response on a yahoo.co.jp
test account:

```
W6 NAMESPACE
* NAMESPACE (("" NIL)) NIL NIL
W6 OK NAMESPACE completed
```

The server greeting is:
```
* OK [CAPABILITY IMAP4rev1 ID NAMESPACE UIDPLUS LITERAL+ CHILDREN XAPPLEPUSHSERVICE AUTH=PLAIN AUTH=LOGIN] IMAP4rev1 imapgate-0.7.68_11_1.61475 imap515.mail.kks.yahoo.co.jp
```

The grammar in https://tools.ietf.org/html/rfc2342 says this is legal,
although I'm not seeing any examples or semantics:

   Namespace = nil / "(" 1*( "(" string SP  (<"> QUOTED_CHAR <"> /
      nil) *(Namespace_Response_Extension) ")" ) ")"

I've opted to have the value pass through as null rather than normalizing it.
This is inconsistent with browserbox's current behaviour for LIST/LSUB in this
case (which I submitted the patches for).  In those cases we normalize to '/',
which I didn't have a great reason for, but I also didn't know what else to do.
It may make sense to revisit that decision in the future.  I've updated the
docs to reflect the current behaviour and that it may change.

In this case it seems like if we're reporting the namespace at all we might as
well report a falsey value so any consuming logic can know that the value is
not to be trusted and should use the delimiter reported by LIST/LSUB.  I do
think we want to report the namespace since the root of "" is useful.

For reference, this is what LIST/LSUB looks like for the (freshly created)
account:

```
W4 LIST
* LIST (\\NoInferiors \\HasNoChildren) "/" "Bulk Mail"
* LIST (\\NoInferiors \\HasNoChildren) "/" "Draft"
* LIST (\\NoInferiors \\HasNoChildren) "/" "Inbox"
* LIST (\\NoInferiors \\HasNoChildren) "/" "Sent"
* LIST (\\NoInferiors \\HasNoChildren) "/" "Trash"
W4 OK LIST completed
W5 LSUB
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Bulk Mail"
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Draft"
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Inbox"
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Sent"
* LSUB (\\NoInferiors \\HasNoChildren) "/" "Trash"
W5 OK LSUB completed
```
andris9 added a commit that referenced this pull request Nov 12, 2014
handle NIL namespace delimiters, update docs
@andris9 andris9 merged commit f36b9e3 into emailjs:master Nov 12, 2014
@andris9
Copy link
Member

andris9 commented Nov 12, 2014

Its hard to imagine why to provide support for NAMESPACE if it doesn't give out any useful information. From the example response I see there is a personal namespace "" (which I already expect to exist anyway) and nothing else.

@asutherland asutherland deleted the handle-nil-namespace-delim branch November 12, 2014 18:03
@asutherland
Copy link
Contributor Author

Yeah, I don't understand that namespace setup at all.

asutherland added a commit to asutherland/gaia-email-libs-and-more that referenced this pull request Nov 20, 2014
This is primarily a move to the upgrade startTLS functionality.  This included
a fix to the SMTP implementation where a server could avoid TLS-initiation by
not implementing EHLO.  (emailjs/emailjs-smtp-client#20).
This goal was bug 1060558.

An additional fix we had made locally but not upstreamed (but have now
upstreamed) and that has improved test coverage on our end (see test_mine) is
a problem relating to newlines.  See
emailjs/emailjs-imap-client#35.

Other (new) fixes folded in here:
- Namespace NIL delimiter: emailjs/emailjs-imap-client#36
- trailing whitespace in bodystructure list:
  emailjs/emailjs-imap-handler#8

Fixes we had made locally and upstreamed but not taken via the release process:
- NIL delimiters for LIST emailjs/emailjs-imap-client#27 and
  LSUB emailjs/emailjs-imap-client#29 (discovered while
  investigating bug 1091295 and bug 1084216)
asutherland added a commit to asutherland/gaia-email-libs-and-more that referenced this pull request Nov 27, 2014
This is primarily a move to the upgrade startTLS functionality.  This included
a fix to the SMTP implementation where a server could avoid TLS-initiation by
not implementing EHLO.  (emailjs/emailjs-smtp-client#20).
This goal was bug 1060558.

An additional fix we had made locally but not upstreamed (but have now
upstreamed) and that has improved test coverage on our end (see test_mine) is
a problem relating to newlines.  See
emailjs/emailjs-imap-client#35.

Other (new) fixes folded in here:
- Namespace NIL delimiter: emailjs/emailjs-imap-client#36
- trailing whitespace in bodystructure list:
  emailjs/emailjs-imap-handler#8

Fixes we had made locally and upstreamed but not taken via the release process:
- NIL delimiters for LIST emailjs/emailjs-imap-client#27 and
  LSUB emailjs/emailjs-imap-client#29 (discovered while
  investigating bug 1091295 and bug 1084216)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants