Protocol Overview: Polymer does...

...ACAP

Polymer was started, first and foremost, as a sort of testbed or proof of concept for ACAP, so obviously it supports a reasonable subset of the draft ACAP datasets, many of which have expired.

In particular, email, personality, bookmarks, and addressbook are all supported classes. And yes, originally, the only reason it supported bookmarks was indeed purely because I can, but it's turned into a bit of a spiffy feature.

ACAP is supported and used very heavily indeed - in particular, only my ACAP server is, as far as I know, fully featured enough to cope. (The Cyrus one is almost good enough, but I hear that DELETEDSINCE still causes it to crash.)

Note that, contrary to popular belief, I developed an ACAP server and client in order to see if my suspicion that ACAP was "good" was true, and I continue to use ACAP because my suspicion appears correct in practise. Show me something better (or help me design something better), and I'll use it happily.

...IMAP

I also have a long-standing fascination with IMAP. Polymer is an online client - meaning it has no 'disconnected' state. It's running off an IMAP library I wrote which tries to use a single connection, heavy caching, and minimal prefetching. This means that it maintains a full cache between sessions, and so it's not quite the same as a cacheless "classic" online client. For the most part, if connectivity to the IMAP server is lost, it behaves as if the latency is simply very high.

It supports a wide array of extensions, both formally published as RFCs and informally as drafts. In some cases, the drafts have expired.

Polymer's IMAP support operates using a single connection. It switches between mailboxes, resynchronizing them on entry. As a result, it's been driven toward very fast resync, and this became obviously useful on low-bandwidth, high-latency links, so I've optimized toward that.

...Submission

Polymer uses Submission to send mail - that's ESMTP, tweaked and extended for maximum benefit to email clients sending mail. It can cope perfectly well with a standard ISP's ESMTP server, but be warned that you won't be able to roam very easily.

Polymer itself uses a facility of the library called "transmission" for sending messages, which effectively takes a description of the message, and causes a message matching that description to be transmitted to various destinations. Gradually, it's becoming more and more capable of transmitting the message to multiple destinations in parallel, including IMAP folders, email recipients, and newsgroups.

...NNTP

Reading news is pointless over low bandwidth, but sending articles (posting) is quite sensible. Polymer has fairly poor support for NNTP, which gets fixed enough to work every time I want to participate in a discussion...

I read the news via IMAP, in case you're wondering.

Links to specifications

The following specifications are intended to be supported. Please let me know if you discover they aren't being. Most of these are actually supported by the Infotrope Python Library, which Polymer uses.

MIME

Basic MIME (RFC2045,RFC2046,RFC2047)

Covered by many standards. The majority of processing Polymer leaves to the IMAP server, however it parses headers and assembles messages itself. The Infotrope Python Library, which is underneath, does have MIME parsing code, but Polymer doesn't (currently) use it at all.

multipart/related (RFC2387)

Supported in full.

Content-Disposition (RFC2231)

Should be supported. RFC3459 is not, yet, but I do intend to get around to that when MDN support goes in.

IMAP

RFCs and drafts, with untested features in italics:

IMAP4rev1 (RFC3501)

Supported. Polymer makes some attempt to drop STATUS, etc, where only IMAP4 is available. However, Polymer is much more efficient at resyncs where IMAP4rev1 is supported.

MULTIAPPEND (RFC3502)

Supported. Not actually available through the UI, however, so not terribly well tested.

BINARY (RFC3516)

Supported both in FETCH and APPEND. Recently retested with Cyrus IMAP 2.3, and the support aided development of Binary upload support in Cyrus IMAP 2.3.4.

CHILDREN (RFC3348)

Supported. I do detect whether \HasNoChildren flags are about, in the case where CHILDREN (or LISTEXT or LIST-EXTENDED) is advertised, I ignore them otherwise, and \HasChildren is always ignored.

ID (RFC2971)

Supported (Viewable using Properties in server context menu)

STARTTLS (RFC2595/RFC3501)

Supported, used automatically where possible. Not all platforms support SSL/TLS connections over non-blocking sockets, so this isn't used on those platforms. (Having PyOpenSSL installed normally fixes this, and I have a fuller PyOpenSSL fork which handles compression and bandwidth octet-counting better.)

NAMESPACE (RFC2342)

Supported. Note that namespace names are not part of this specification - the ones Polymer uses are internally generated. The Internationalization draft gives us names, incidentally, but we don't (yet) support that one.

MAILBOX-REFERRALS (RFC2193)

Supported, but caveat: it's slow - an entire connection-cycle is required to open a mailbox, which takes a lot of blocking time.

IMAP URLs (RFC2192)

Not an extension. Polymer can operate with full IMAP URLs, as far as I'm aware. These are used with CATENATE, BURL, and URLAUTH, as well as for bookmarks.

IDLE (RFC2177)

Polymer can also cope where some classes of message are not issued when IDLE, and will intersperse IDLE commands with NOOP in the case where the remote server hasn't yet issued any useful responses.

UNSELECT (RFC3691)

Supported. Where this is unavailable, it'll issue a SELECT with a hopefully impossible mailbox argument.

ACL/RIGHTS (RFC4314)

Supported read-only. In other words, this is used for MYRIGHTS only, you can't change ACLs with Polymer yet. Note that Polymer works with RFC2086 based servers as well as the more advanced RFC4314.

LITERAL+ (RFC2088)

Uses thse for small literals, or when sending non-first large (>1024) literals.

UIDPLUS (RFC4315)

Polymer doesn't yet prime the cache on an append, however, but does use this for COPY and APPEND URL generation.

CATENATE (RFC4469

Used for certain stateless, non-flag COPY replacements as well as for simply storing messages.

ESEARCH (RFC4731)

Which I co-wrote with Alexey Melnikov, so it'd be embarrassing if it weren't supported. Tested against Isode's M-Box IMAP server, which is part-written by Alexey. I've also privately implemented this in Cyrus IMAP 2.3.

CONDSTORE (RFC4551)

Polymer's hybrid online/disconnected model works favourably with CONDSTORE. Polymer only uses the CHANGEDSINCE modifier to FETCH.

LIST-EXTENDED (ietf-imapext-list-extensions)

Used for various things.

LIST-SUBSCRIBED / LISTEXT (Old variant of above)

Supported as fallback, used to replace [R]L{IST|SUB}.

ACL2 (Draft expired)

Drop-in replacement for the MYRIGHTS commands Polymer normally issues. With ACL2, it'll use MYRIGHTS returns.

SASL-IR (siemborksi-imap-sasl-initial-response)

Polymer always uses Client Send First if available, for DIGEST-MD5 reauth and ANONYMOUS authentication.

POSTADDRESS (melnikov-imap-postaddress)

Polymer can use POSTADDRESS in order to transmit messages directly to mailboxes.

URLAUTH (RFC4467)

Polymer uses URLAUTH to submit messages via BURL, if available.

ESMTP

RFCs. Submission extension support is currently quite poor, hence some RFC status extensions are tested only on Isode's M-Switch implementation:

ESMTP (RFC2821)

Supported, however the code is primarily designed for submission, hence:

Submission (RFC2476)

Supported.

8BITMIME (RFC1652)

Using a Late Message Assembly technique.

BINARYMIME (RFC3030)

Again, this is supported via the Late Message Assembly technique. I've only tested this against my own (very shoddy) submission server.

CHUNKING (RFC3030)

Used by default where available. As above, only tested against my own rather poor submission server.

PIPELINING (RFC2920)

Including when mixed with CHUNKING and BURL. Polymer is quite conservative about Pipelining - in particular, it doesn't pipeline AUTH, and will clear the pipeline before sending message data.

STARTTLS (RFC3207)

Supported where the platform allows. Currently (with Python 2.4) this appears to be everywhere.

AUTH (RFC2554)

Supported and passed through to the SASL implementation. The SASL implementation doesn't let Polymer know when it's safe to pipeline AUTH, however.

BURL (RFC4468)

Note that this is only used for a complete message when URLAUTH and UIDPLUS are available on the "staging" IMAP server, and you've set either a Drafts folder or a Sent folder. For message portions, or forwarding, it can be used as part of a CHUNKING remote message assembly, or chunk and assemble using CATENATE on the IMAP server.