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

Adrien de Croy <adrien@qbik.com> Sat, 18 February 2012 07:24 UTC

Return-Path: <adrien@qbik.com>
X-Original-To: imap5@ietfa.amsl.com
Delivered-To: imap5@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC28921F8699 for <imap5@ietfa.amsl.com>; Fri, 17 Feb 2012 23:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.826
X-Spam-Level:
X-Spam-Status: No, score=-3.826 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAKlc7uj0ycO for <imap5@ietfa.amsl.com>; Fri, 17 Feb 2012 23:24:38 -0800 (PST)
Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9133721F852B for <imap5@ietf.org>; Fri, 17 Feb 2012 23:24:37 -0800 (PST)
Received: From [192.168.1.10] (unverified [125.237.241.8]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018869579@smtp.qbik.com>; Sat, 18 Feb 2012 20:24:36 +1300
Message-ID: <4F3F5234.2080406@qbik.com>
Date: Sat, 18 Feb 2012 20:24:36 +1300
From: Adrien de Croy <adrien@qbik.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0
MIME-Version: 1.0
To: Dan White <dwhite@olp.net>
References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <alpine.LSU.2.00.1202161626400.30682@hermes-2.csi.cam.ac.uk> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <CABa8R6uxeFVSDQzzSS6ziV8b2roYdw38GMpjEm+1DGkhD3MdVg@mail.gmail.com> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net>
In-Reply-To: <20120217171457.GB4503@dan.olp.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP
X-BeenThere: imap5@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion on drastically slimming-down IMAP." <imap5.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imap5>, <mailto:imap5-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imap5>
List-Post: <mailto:imap5@ietf.org>
List-Help: <mailto:imap5-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Feb 2012 07:24:38 -0000

On 18/02/2012 6:14 a.m., Dan White wrote:
> On 02/17/12 13:51 +1300, Adrien de Croy wrote:
>>> imap essentially already has its own mail submission component via imap
>>> append. Users can trust who sends them messages, and can limit who can
>>> send them messages (via enforceable acls). I just wish smtp worked more
>>> like that, but that's a pipe dream.
>>>
>>
>> I don't know how you can use APPEND to send a message to another user 
>> unless you share a folder with them.
>
> 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?). 
in some parts of the world dialup is still prevalent.

We can't presume everyone has a full time internet connection.

If the sender and receiver are both in this category, (which is common 
in such places) then finding an intersection in times for delivery if we 
only have end-to-end delivery could result in significant delays.  
Therefore store-and-forward is required.


> They authenticate over sasl using some fancy
> federated authentication protocol (project moonshot) before being allowed
> to post to my inbox.

Personally I'd be tempted to mandate use of X.509 (SSL) client certs and 
TLS.

Citizens and organisations of a country would have certs which were 
issued and vouched for by their government.

Every submitter into the secure mail system would require a cert, and 
abusers would have their cert revoked (and be fined/punished).

ISPs could vouch for clients, but could have their cert revoked if they 
supported spammers.


> 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.
>
I believe it's rooted in the lack of responsibility.  Responsibility for 
the actions of a mail sender is not enforced.

Computers can't be tried and sent to jail.  They can't be responsible 
for their actions.  Only humans can.  So the concept of a computer doing 
something where no person holds responsibility for it is nonsensical.

To hold someone accountable for an action of a computer, that person 
must be identifiable as the sponsor of the action.  Certificates can do 
that.  Hence government involvement, since governments are the 
organisations responsible for establishing the identity of their citizens.


-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com