Re: [Endymail] spam versus cleartext

Dave Crocker <dcrocker@gmail.com> Sun, 07 September 2014 15:30 UTC

Return-Path: <dcrocker@gmail.com>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50331A041F for <endymail@ietfa.amsl.com>; Sun, 7 Sep 2014 08:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BxtNepYasEy for <endymail@ietfa.amsl.com>; Sun, 7 Sep 2014 08:30:43 -0700 (PDT)
Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A9B1A010C for <endymail@ietf.org>; Sun, 7 Sep 2014 08:30:43 -0700 (PDT)
Received: by mail-qc0-f175.google.com with SMTP id c9so14342939qcz.20 for <endymail@ietf.org>; Sun, 07 Sep 2014 08:30:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uUpYODOdk7M5ZKVsQvH5905SQjH+YIB9LvWmiMZ1ekg=; b=0h7NQFBjHL43/qYPshrF2Hbc5CTihv8ZliIB+Av6kOGSdrF8YdZgqdukGy3yosywyz 5+5SP3QoJjslwgqt7vxNHUezCwn4oKPpqIM4ENIj3yCx0o7v3jzHbj2LHjlvz9/vY+dm GTPwJ661rNzzhUWSfkV1nqiXZbW2qYeuwGHtlLW+DHeX2YyZXNmwyCQXjF5iwrzXixxV i7mjVUsKOPs/5BI4lfkXbWcamgsvRm3ZUyJEL65Ai7xwXFCb7KAKOTXT6sodpuMVIcuL 8YV6HIWj0HpfZfKOwwOcQEjf9ZCQDWfcZGVBXPqu799TnaDapGeoFGckxZ9It56U4cx9 FK6w==
X-Received: by 10.224.80.65 with SMTP id s1mr33846130qak.41.1410103842592; Sun, 07 Sep 2014 08:30:42 -0700 (PDT)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id o1sm5608768qaa.19.2014.09.07.08.30.40 for <endymail@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 08:30:41 -0700 (PDT)
Message-ID: <540C7963.8040204@gmail.com>
Date: Sun, 07 Sep 2014 08:27:31 -0700
From: Dave Crocker <dcrocker@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: endymail <endymail@ietf.org>
References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <CAMm+Lwh1JJQTOgRN_31b3+oTreeHzntBxx5sNeAFQAwnac9trw@mail.gmail.com> <29088157-04F4-4E22-A604-A35C3B217C98@gmail.com>
In-Reply-To: <29088157-04F4-4E22-A604-A35C3B217C98@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/XH-2Egu0JQ9h2scgbyl4ouHvxvM
Subject: Re: [Endymail] spam versus cleartext
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Sep 2014 15:30:45 -0000

On 9/7/2014 8:10 AM, Kathleen Moriarty wrote:
> How does handing not only spam, but other attack like phishing and spear phishing evolve when e2e messaging is the norm?


Spam and other abuse continue to occupy 90-98% of the email traffic
across the net.  Life is tolerable only because the receiving operators
have gotten quite good at keeping these barbarians outside of the gate.
 Note that a change of only a few percent in filtering efficacy will
likely double the amount of spam/abuse the receivers sees.  And double
is a best case scenario.

Modern filtering engines use an amazing array of information to assess
incoming mail.  IP Address, message meta data, content, traffic
analysis, etc.  Some of the filtering does not require looking at any
content (envelope, header, body).  Some does.

To the extent that particular content is hidden from the filtering
engine, that portion of the engine is useless.  (This observation is in
the realm of "duh", but it's needed for the sequence here.)

If that efficacy is to be retained/recovered, we need to find a way to
give the filtering engine access to that data, but without compromising
the confidentiality model.

As this has been discussed in other conversations, the only way I see
that happening is to move the relevant portions of the engine into the
recipient's MUA, and then have that sub-engine consult with the main
engine.  ("Consult" is a code word for needing an open protocol between
the MUA and the filtering engine.)

This will let more bad mail get to the inbox, but would still limit how
much actually burdens the recipient.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net