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

[Bron Gondwana <[e-mail]>]

On Fri, Feb 17, 2012 at 02:05:47PM -0600, Dan White wrote:
> On 02/17/12 20:40 +0100, Bron Gondwana wrote:
> >You have an excellent point that unavailable endpoints and incomplete
> >routing really are almost entirely a thing of the past.  There are still
> >some network structures where things aren't directly connected to the world,
> >but IPv6 should solve the remaining routability issues.
> 
> I don't think the disconnected state really matters. The email could just
> sit in a local queue until it's reconnected to the network, at which point
> it could be send directly to the recipient's lmtp server (which makes
> better sense than direct imap, now that I think about it).

Not if you want to solve non-delivery notifications as well.  Otherwise,
store and forward isn't too bad.  I'd love if it had a return path all
the way through, so each intermediate didn't delete its local copy
until EVERYONE had confirmed it to the destination.  It would help
with retryability too.

But that depends on Message-Id being not played fast-and-loose with,
and that boat sailed :(

> >BUT - for me at least, I don't want to solve this problem.  It's a massive
> >problem for sure.  I'm not interested in your "point 3" though.  It puts the
> >administrative burden of adding every webshop I've ever used to my whitelist
> >on to me.
> 
> It's the same burden that Facebook users have, and points to the advantage
> that Facebook and Facebook like services have, one in which they have
> perfect knowledge of who's sending messages to who. It makes stopping spam
> a lot easier. I suppose someone you don't know could send you 10,000
> invites, but Facebook will just deliver one of those. Or one of your
> friends goes crazy and annoys you will 100 messages, as which point you
> remove them from your list.

I know.

> Are the younger folks coming up today going to use email if the spam
> problem isn't solved? I doubt it. SMS and Facebook seem to suit most folks
> under age X (where X will continue to increase linearly over time).

I have a whole talk about this that I've given a couple of times now.
I think there are slides online from at least one set of it.

Basically, "social networks are good for fun, email is for serious
stuff".  I pointed out that I have code from 10 years ago, and emails
from even longer than that, that still works pefectly.  I can still
access it all.  No "404", no "lost in a site redesign into a new
timeline", no "deleted by sender".  It's my copy, and it's immutable.

In other words, it behaves a lot more like a piece of paper.

I use facebook for social stuff - but I email copies of our internal
IRC logs to myself, and all my instant messaging chats - because once
it's in email, it's accessible everywhere, it's searchable, and it
doesn't disappear.

> imap, smtp, and even exchange are pretty much doomed to role of legacy
> enterprise application if that continues.

That's definitely a concern.

> >(in this theoretical world you could talk direct SUBMISSION to the remote
> >users' servers and not even involve your IMAP$n server at all, given a
> >federated authentication)
> 
> I don't really even think there needs to be a change to the basic imap/lmtp
> specifications to support my grandios plan for eradicating spam (although
> I'm far from the first to have such a light bulb go off). As soon as the
> appropriate sasl mechanisms are in place to support some federated
> authentication (think authentication against Facebook), then all that's
> left is to improve ACL support in servers and clients. Simple matter...

Heh.  Go for it.  I'll support your crusade, but I won't lead the charge on
this one.  Client/Server is my baby.

Bron.