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

[Bron Gondwana <[e-mail]>]

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.

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.

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)