Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

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

On 17/02/2012 12:22 a.m., Dave Cridland wrote:
> On Thu Feb 16 10:58:51 2012, Adrien de Croy wrote:
>>
>>
>> On 16/02/2012 11:41 p.m., Dave Cridland wrote:
>>> On Thu Feb 16 10:15:04 2012, Adrien de Croy wrote:
>>>> But SRV has issues, not every corporate runs their own DNS (at 
>>>> least not for external).
>>>>
>>>>
>>> Well, tough. There is a point at which we have to assume people will 
>>> have to fix things. XMPP services get this fixed pretty quick, and 
>>> mail is a much bigger juggernaut.
>>>
>>>
>> how many corporates deploy XMPP services?
>>
>>
> Approaching 10% and growing, at least by some metrics:
>
> http://eggert.org/meter/xmpp.html

OK.. I'm struggling to understand why...


>
>> SRV is great, but it's only marginally better than ACAP in terms of 
>> conifguration points.  You still need a domain.  What happens when 
>> you're using hosted mail?  Does your mail host have to give you a 
>> sub-domain so you can have your own SRV record to point to your own 
>> ACAP server to get your mail config?
>>
>>
> You've gone off on one.

hmmm, you're right I have!!!! what was I thinking...

>
> If you have a mail domain, then you can put in SRV records to point to 
> the servers. If you use another mail domain, then they do that for you.
>
>
>> How many points of failure there?
>>
>>
> Lots - but no fewer than without. Unless you think that SRV might 
> break when the rest of the DNS doesn't. I don't think that's been an 
> issue for the past decade or so.

no I wouldn't expect its reliability to differ from any other records.

>
>> That's why I keep going back to the 1 port like a broken record.  
>> Maybe it should just be an SSH tunnel... but that;s back-pedalling 
>> quickly and reducing potential user experience with it.
>>
>>
> No, I think it's an orthogonal issue.

maybe, but nonetheless real, especially for ISP tech support staff.

Just trying to think of "cheap" ways to get single sign on and single 
port using the existing protocols.  But it would still be a bandaid.

Auto config is a band-aid as well to the solution of multiple sets of creds.

>
>>>> ACAP is great too, but it's another port and set of creds.  And the 
>>>> tie-in between ACAP and other services is probably manual on the 
>>>> back-end right?
>>>>
>>>>
>>> What tie-in? ACAP's just a simple store. The enhancement to the 
>>> client is that a sysadmin can preconfigure the clients, and ACAP 
>>> gives a bunch of wacky data inheritance tricks to make this easy.
>>
>> as I said - manual.  You have to type in the settings, the IMAP 
>> server can't publish them automatically to the ACAP server.
>>
>>
> Oh, right.
>
> Well, yes, it *can* - both WorldMail and CommuniGate work(ed) in this 
> manner.
>
> But given the sysadmin has to make precisely one STORE command on a 
> real ACAP server, it's a bit of a non-issue - it no more manual than 
> setting up any other server.

ok


>
>>>> Xtra is NZ's biggest ISP.  It blocks port 25.  So when I take my 
>>>> laptop home I need to reconfigure it.  At least I know how to do that.
>>>>
>>>>
>>> Why would blocking port 25 be a problem? Unless you're running an 
>>> MTA on your laptop, in which case you're presumably savvy-enough to 
>>> deal with the consequences.
>>
>> there are a myriad of reasons.  My MTA is Thunderbird.  At work, I 
>> have my mail set to send to smtp.qbik.com with creds.  When I take my 
>> laptop home, I can't connect any more.  I have to send my mail 
>> through the ISP mail server.  Some companies don't like this.  Some 
>> users have trouble configuring this.  We do actually get support 
>> tickets created by this particular issue.
>>
>> You go to a hotel, same issue.
>>
>> Some companies use SPF as well, so mail starts to bounce when you 
>> can't use your corporate MTA to send.
>>
>>
> Right, sure, understood (after s/MTA/MUA/) but what has port 25 got to 
> do with it?

back to my point about getting everything over 1 port.  If we had that, 
then blocking 25 wouldn't have affected me.

>
>>>> We're techies here, we forget how lost and confused the punters get.
>>>
>>> No matter how good the protocols involved are, it comes down to how 
>>> good the deployment and implementations are. The client is the 
>>> punter-facing component, and without good clients you're shot 
>>> whatever you do.
>>>
>> absolutely.  But good clients can be impossible to achieve if the 
>> protocols don't allow it.
>>
>>> To get "good" clients, you need mind-share, and you'll only get that 
>>> if you start off with the status quo and figure out where to go - or 
>>> if you base on another preexisting framework. Lots of folk are doing 
>>> this very successfully with the web, of course, but I think there 
>>> are other options, too.
>>
>> Microsoft abandoned it all and wrote Exchange.  So did GMail.
>>
>>
> GMail did it with the web - preexisting framework. Then they leveraged 
> the deployed base of mobile IMAP clients - preexisting framework.
>
>
>> They can afford to do that.  We aren't MS or Google.
>>
>>
> Apparently not...
>
>
>> Why do you think they did that?  Exchange server was delayed for 
>> years.  It cost them.  But now it's almost the only game in town.
>>
>>
> Exchange was largely an X.400 system, until recently. Again, they 
> didn't make any real attempt to reinvent the wheel.
>
> What they did do was carefully market it - Outlook was a very nice 
> client, and it came free with Office, and only really worked tolerably 
> with Exchange - where it worked really quite well. So they managed to 
> leverage from Windows to Office, and from Office to Exchange.

Actually last time I compared prices of versions of Office, the Outlook 
component accounted for like $500 NZ.

It's also possibly the worst IMAP implementation out there.  But they 
don't _want_ you to use IMAP.   They want you to buy Exchange.

>
> The fact that it's a monolithic protocol has little to do with it.
>
>
>
>>> All this talk of a boil-the-ocean brave-new-world is great fun, I'll 
>>> be the first to admit, but I really don't see how it gets us 
>>> anywhere useful.
>>
>> I prefer my ocean at ATP.
>>
>> We could just talk about what could be stripped out of IMAP.  But I 
>> don't really see how that would get us anywhere useful either.
>
> Sure.
>
> What we need to do is identify the core problems to be solved, instead 
> of finding solutions and trying to figure out how to use them.

* SPAM
* UDNs
* configuration issues

solve any one of these and you'll make a lot of people happy.

Adrien


>
> But it's not nearly as much fun.
>
> Dave.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com