On 16/02/2012 1:26 p.m., Brandon Long wrote:
This is the second time I've heard about concern that proxies would
break access to my mail data over http.
layering other protocols over HTTP is currently an arms-race between
client-software developers who want to do this, and proxy developers who
want to provide the tools their customers (sys admins) ask for to allow
them to prevent it.
the harder it gets to block something intelligently, the more likely
admins will resort to over-blocking. We see it every day.
Developing a new protocol for mail designed ONLY to layer over HTTP is
therefore extremely foolhardy. Sure by all means have options.
HTTPS is no different. There are already proxies that scan and restrict
https.
IMO we'd be better off designing a protocol that is clearly identifiable
(e.g. port) and easily able to be restricted. Then it is more likely to
be explicitly permitted than fall victim to overblocking. I wonder what
will happen when malware authors start using BOSH for instance, how long
it will be before it's locked down. We already see malware using https
/ CONNECT which results in those services being locked down.
I agree re encryption, but IMAP already has STARTTLS. (what I'd like to
see is mandatory client certs for mail sending)
Adrien
Take those issues out of the loop, use https instead. That way, the
data's encrypted end-end anyways, which of course it should be.
I know people hate dealing with certs, but I think we're well past the
point at which people want their personal mail traveling unencrypted
from their mailstore to their client.
Brandon
On Wed, Feb 15, 2012 at 1:28 PM, Adrien de Croy<[email protected]> wrote:
having dealt with support issues relating primarily to HTTP for the last 17
years, I'd STRONGLY recommend against using anything HTTP based. The number
of proxies that break WebDAV makes it problematic alone.
If some clients need HTTP-based access to some IMAP function, they can use a
gateway.
Then an administrator can choose whether to allow such access. But clients
using the protocol that provides it all don't need it.
If you're a system admin, and there's a product you can install where you
install 1 service, open 1 port and it provides everything you'd go for that
right?
If we play our cards right, it should be simple for some gateway to provide
legacy interfaces to the new protocol.
re the discussion about richness of protocol... sure you can do things at a
lower level. That typically requires more round-trips to the server though.
unless the things are pipelined..... specifically designed to be, so a
single meta command is sent as a bunch of micro commands... but therein lie
a multitude of problems (e.g. enforcing security, synchronisation etc).
Adrien
On 16/02/2012 10:13 a.m., Bron Gondwana wrote:
On Wed, Feb 15, 2012 at 09:59:56PM +0100, Michel Sébastien wrote:
On 15/02/2012 14:19, Bron Gondwana wrote:
On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote:
Is there any reason to keep subscriptions in IMAP 5 ?
I envisage "subscription" as either an annotation or a "Special Use"
on a folder rather than yet another axis of data.
+1.
Does it works with shared folders ?
Sure, it's a private annotation.
This is not a problem that's unique to email. There's nothing really
special about email here unless you make it special. Sure there's a bunch
of indexed and optimised ways of viewing that data - sort by trimmed
subject, encodings, etc. All of which could be expressed as generic queries
against the data model with a query optimiser on the far end rather than
needing a custom syntax for everything...
Some others seems to think that webdav could be a candidate :
http://www.webdav.org/other/faq.html#Q26
A new layer on top of webdav, with some keywords registered at IANA. But
I just don't like the trend to use HTTP for everything... despite its
interest here.
Yes, webdav is tempting for a few reasons - the downside is
a relatively high overhead.
BEEP has also been mentioned. A good advantage of both of
these is that you can transport unmodified MIME across them.
I'm wary of anything which will require the raw MIME bodies
of messages to be encoded across the wire - some sort of
length based literal syntax is very valuable.
Of course it's hard to love something with examples like this:
S: RPY 0 1 . 221 185
S: Content-Type: application/beep+xml
S:
S:<profile uri='http://iana.org/beep/SASL/CRAM-MD5'>
S:<![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
jaS5uZXQ+</blob>]]>
S:</profile>
S: END
It makes MIME header encoding look so lightweight in comparison.
Still... as I'm regretting learning, compatible is more important
than good. If there exist libraries everywhere which can
reliably read and write that, and it's ugly enough that nobody
wants to do it themselves, then maybe - just maybe, you'll actually
get BETTER complience than if it's a simple enough protocol that
people roll almost-correct code by hand.
Bron.
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
