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

[Dan White <[e-mail]>]

On 02/17/12 20:40 +0100, Bron Gondwana wrote:
>On Fri, Feb 17, 2012 at 11:14:57AM -0600, Dan White wrote:
>> That's exactly what I want. I want to configure my ACLs to allow specific
>> users to connect via IMAP (or an SMTP replacement). If someone wants to
>> send me a message, their client connects directly to my server (why is
>> relay still necessary?). They authenticate over sasl using some fancy
>> federated authentication protocol (project moonshot) before being allowed
>> to post to my inbox.
>>
>> 1) The need for submission-and-relay goes away.
>> 2) I can trust the identity of who's sending me a message.
>> 3) I can fiddle with my acls bits to determine who I want to get messages
>> from.
>>
>> When relay is *really* necessary, sasl authorization to allow servers to
>> act on behalf of domains/users should do the trick.
>>
>> In my opinion (and I admit I'm getting off topic), spam is merely a problem
>> rooted in relay.
>
>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).

>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. 

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).

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

>Sure it may be technically feasible - but it's just not the pain point that
>_I_ am feeling, so it's not in my vision of a replacement protocol for IMAP.
>I'm purely concerned with communications between the user agent and their
>remote data store/server.
>
>Bron.
>
>(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...

-- 
Dan White