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
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
