Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-03

"Murray S. Kucherawy" <superuser@gmail.com> Wed, 29 May 2013 07:05 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDD221F856D for <apps-discuss@ietfa.amsl.com>; Wed, 29 May 2013 00:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 Crcydv4mzyTw for <apps-discuss@ietfa.amsl.com>; Wed, 29 May 2013 00:05:55 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 67D7B21F855F for <apps-discuss@ietf.org>; Wed, 29 May 2013 00:05:55 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id y10so6407417wgg.16 for <apps-discuss@ietf.org>; Wed, 29 May 2013 00:05:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U6V/D1DSS3yXrMmMi+fH4NLI9PuN4uwa7VJT/Ei1JOs=; b=SS9IpI4IiIbfeYfBCYpmM3C/iqyIX7eY3rf8FxEog1yt9PwaZhMUXdifhy+h7lLHWn vqba57EpxSY9aAaf1fg/As4+ceqB1IoyZ6P2hOjaeZaQDnL7p+UJfKLFyAB8JfH4hl6b 5wdIq0/GB+16Zoo2VS+CK8HMwcgfa0H4J8G7Qk2UV39SUSrFCMhkVyce//c23m12Gk07 rqJv53jNNrWA3AoaGUs50A/hHunmtJggsEX5zoC5qKB3vBfHi7T6TBhRQ0w9l5Fq5UbZ tBIqzYqtowYELU5A5THoMMDF+L/LzEJhC/ONY/1lZOZrt3gf4HkYE4v6ysnQRS7lshR0 sfOw==
MIME-Version: 1.0
X-Received: by 10.180.20.208 with SMTP id p16mr1006750wie.59.1369811154578; Wed, 29 May 2013 00:05:54 -0700 (PDT)
Received: by 10.180.74.203 with HTTP; Wed, 29 May 2013 00:05:54 -0700 (PDT)
In-Reply-To: <01OU6TEMJ65Q000054@mauve.mrochek.com>
References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <alpine.BSF.2.00.1305152133120.63512@joyce.lan> <CAL0qLwb8gzOvC6eXmg+0+etuiTrdRMQyNBOk7BMns-Csfj4Wxw@mail.gmail.com> <01OTSF48H616000054@mauve.mrochek.com> <alpine.BSF.2.00.1305182237110.74365@joyce.lan> <CAL0qLwYUEsoHLs1_1Rb6ipEyjqBVLkFpTdhge_Q215=csETM-g@mail.gmail.com> <01OU6TEMJ65Q000054@mauve.mrochek.com>
Date: Wed, 29 May 2013 00:05:54 -0700
Message-ID: <CAL0qLwaiEM8wtWyR-0cWzYNng43xUhNiWvsDWupb_-Fm0W5umQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Ned Freed <ned.freed@mrochek.com>
Content-Type: multipart/alternative; boundary="bcaec53f38c94731a604ddd60346"
Cc: John R Levine <johnl@taugh.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2013 07:05:56 -0000

On Tue, May 28, 2013 at 5:50 PM, Ned Freed <ned.freed@mrochek.com> wrote:

> > Consider a system that has several independent filtering modules.  It's
> > important that the modules don't change the content as it passes from one
> > to the next as doing so might obscure something that the next module
> might
> > consider reject-worthy.  Therefore, whatever transformations need to be
> > done have to be kept internal to the module and not released as the
> "real"
> > content.
>
> It's nowhere near this simple. Sometimes you want filtering modules exposed
> to unadulterated content. One way to arrange for that is preclude any
> changes, but another is to run the modules in parallel. After all, if
> they're
> not talking to each other, why wouldn't you want them to run
> simultaneously?
>
> But other times you want them to be able to pass information to each other.
> Unfortunately that often can only be done by adding headers. And there are
> even times when you want much more radical transformations applies, such
> as the removal of encryption, forced conversion to MIME format, etc. etc.
>
> There really isn't a one size fits all answer here, and it's silly to think
> one can be found.
>

The -05 version of this document makes it clear that we're talking about a
system where the handling modules operate in a sequence, since that's the
model I had in mind when I rewrote that text.  I'll add some additional
prose about the points you've made here.

-MSK