Re: [apps-discuss] update to rfc5965

SM <sm@resistor.net> Mon, 08 July 2013 05:16 UTC

Return-Path: <sm@resistor.net>
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 5DD1911E8177 for <apps-discuss@ietfa.amsl.com>; Sun, 7 Jul 2013 22:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 u2h8-0-H764Z for <apps-discuss@ietfa.amsl.com>; Sun, 7 Jul 2013 22:16:23 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF3C11E8151 for <apps-discuss@ietf.org>; Sun, 7 Jul 2013 22:16:23 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r685GHJU017447; Sun, 7 Jul 2013 22:16:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373260582; bh=AmHQjHn+HG10izipSp76btkeES15KVK1bEUgvp6o1zg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OIcFBNaUsWGEOe1/Du/W0s9jNDTH4NYu4bpI8QwLP2URqEFM8RvOUGpCplKIhYkJc tcGTnlAOfzyreLa7hkAt4rOPDJJl1dvta+KTp/zM/8sXUrx9q0KISREO5KK0DsoON1 zO1AjTHIPM9me7F4Xvd5oyE7SoZDLpG8rHa25bR4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373260582; i=@resistor.net; bh=AmHQjHn+HG10izipSp76btkeES15KVK1bEUgvp6o1zg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f7O9sspuNNiUw2/btA4I26WX8Q5Go1UQ2ndgVDTTwXFm6x6qqRwEJnIrS46vzhbLN tU4GO2dt+NhKQ0uiIUUPM7H9oApk8SuD3WcoNoRW0H4QKpiGjwP1H4lfMZ6hURtzHE YHZax+TOLbARU/F7fGxEMuUTyA3KgFdQXspbX980=
Message-Id: <6.2.5.6.2.20130707210040.0b869ae0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 07 Jul 2013 21:43:29 -0700
To: Franck Martin <franck@peachymango.org>
From: SM <sm@resistor.net>
In-Reply-To: <47488958.173803.1373149894362.JavaMail.zimbra@peachymango. org>
References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] update to rfc5965
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: Mon, 08 Jul 2013 05:16:24 -0000

Hi Franck,
At 15:31 06-07-2013, Franck Martin wrote:
>http://tools.ietf.org/html/rfc5965
>
>Specifies the format of Abuse Reporting Format of emails.
>
>2.d indicates the report should contain either the headers of the 
>reported email as a text/rfc822-headers MIME part or the complete 
>message as an message/rfc822. However if the message reported 
>contains spam, virus, bad links, or in general malware, the complete 
>report is likely to be discarded by the receiver anti-spam filters, 
>never reaching abuse desks for processing.
>
>It is common amongst security professionals to exchange such 
>dangerous payloads as an encrypted zip file with the common password 
>"infected". This format allows to bypass anti-spam filters as the 
>MTA/MUA is not able to decrypt the attachment to analyze the content.
>
>It i difficult to request abuse desk to create a separate email 
>infrastructure for abuse@example.com and especially to disable 
>anti-spam and anti-virus checks. Some of these addresses are part of 
>email hosted in the cloud.

One of the purposes of the report is to inform the operator about 
email abuse.  In my opinion such a message might have usually 
undesirable content.  The problem is that the operator is using a 
content filter for their abuse mailbox.  It is well-known that it's 
not a good idea to do that.  Whether they do that because they are 
using the "cloud" is immaterial.  When something is difficult for 
non-technical reasons it is ample reason not to try to fix it by 
technical means unless profit is all that matters.

Security professionals exchanging dangerous payloads by using with 
encrypted to bypass content filters can be described as being 
realistic or something else.  After all, if security professionals do 
that, other people can do that too.

>I suggest we add the possibility to send the complete email as 
>message/rcf822 email within either an encrypted zip file or within a 
>GPG symmetrically encrypted file, both using the common password "infected".

The problem is not the suggestion.  It's what will happen after that.

Regards,
-sm