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

Adrien de Croy <adrien@qbik.com> Fri, 17 February 2012 00:52 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 8061321E8083 for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 16:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.958
X-Spam-Level:
X-Spam-Status: No, score=-3.958 tagged_above=-999 required=5 tests=[AWL=-1.359, 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 q0K7y89XagOB for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 16:52:03 -0800 (PST)
Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id AB95621E808A for <imap5@ietf.org>; Thu, 16 Feb 2012 16:52:02 -0800 (PST)
Received: From sago.qbik.com (unverified [192.168.0.3]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018867439@smtp.qbik.com>; Fri, 17 Feb 2012 13:52:01 +1300
Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.3] (WinGate SMTP Receiver v7.0.8 (Build 3364)) with SMTP id <0010060869@sago.qbik.com>; Fri, 17 Feb 2012 13:51:50 +1300
Message-ID: <4F3DA4A6.5020304@qbik.com>
Date: Fri, 17 Feb 2012 13:51:50 +1300
From: Adrien de Croy <adrien@qbik.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0
MIME-Version: 1.0
To: Dan White <dwhite@olp.net>
References: <3077.1329388899.383165@puncture> <4F3CE16B.3060603@qbik.com> <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>
In-Reply-To: <20120216232954.GB5356@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: Fri, 17 Feb 2012 00:52:07 -0000

On 17/02/2012 12:29 p.m., Dan White wrote:
> On 02/16/12 14:57 -0800, Brandon Long wrote:
>> On Thu, Feb 16, 2012 at 2:41 PM, Dan White <dwhite@olp.net> wrote:
>>> However, spam is a problem caused by a deficiency (or whatever you 
>>> want to
>>> call it) within the smtp protocol. imap does not directly or 
>>> indirectly lead
>>> to the generation of spam, unless you want to consider backscatter 
>>> from a
>>> sieve notification to be spam.
>>>
>>> smtp (or submission) is one of those things that's actually easy to
>>> configure in an email client. I fear that if the two get combined on 
>>> the
>>> same port that imap server IPs may start to get caught up in the cat
>>> and mouse game spam parsers play.
>>
>> IMAP playing the game is no different than SMTP-MSA playing the game,
>> it still requires authentication.  I'm not sure how wide-spread it is,
>> but we certainly already have to deal with spam through spammy
>> accounts or hijacked accounts over SMTP-MSA.  I find it hard to
>> believe that IMAP doing mail submission is going to change any of
>> that, but perhaps you mean that you would have to have the same smarts
>> for protecting against bad logins in IMAP that you have in SMTP-MSA...
>> but I would expect anyone who's under attack for either already does
>> that as well (we certainly use the same auth backend for both.
>
> Separating imap from submission allows those functions to (easily) run on
> separate servers, like where the smtp server is a black box appliance,
> which is not uncommon in the service provider or enterprise space.
>

Whichever way you do it, BURL vs SUBMIT, there is an issue of trust if 
the 2 servers are in different realms.

And those issues were addressed in the BURL RFC, and the same security 
conditions apply.

Notwithstanding all of that.  It's still easier for a developer to hook 
up a way for an IMAP server to submit mail to SMTP than it is to hook up 
SMTP to retrieve IMAP.

If the servers are on the same computer, it can be as simple as a file copy.

One option would be an extension for submission that would only be 
available if the SMTP server trusted the IMAP server.

That would then avoid the need to smuggle SMTP creds across your IMAP 
session (c.f. the way that BURL specifies IMAP creds in BURL requests).

I think in most organisations this would prove a lot simpler to manage.  
Certainly a lot simpler to code as a developer.

Maybe it should be an optional extension, usable as an alternative to BURL.

I'd still be keen on any deployment stats on BURL.

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

Adrien



-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/