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