Re: [imap5] Designing a new replacement protocol for IMAP

[Adrien de Croy <[e-mail]>]

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<[e-mail]>  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
>>> [e-mail]
>>> 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
>> [e-mail]
>> 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/