[marf] Including Mail fields in IODEF

"Moriarty, Kathleen" <kathleen.moriarty@emc.com> Thu, 21 February 2013 10:19 UTC

Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: marf@ietfa.amsl.com
Delivered-To: marf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCF621F8E50; Thu, 21 Feb 2013 02:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=1.265, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnlFKt3GgrLl; Thu, 21 Feb 2013 02:19:28 -0800 (PST)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id EDBEB21F8E4A; Thu, 21 Feb 2013 02:19:27 -0800 (PST)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1LAJQru011582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 05:19:26 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 21 Feb 2013 05:19:12 -0500
Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1LAJCCA004696; Thu, 21 Feb 2013 05:19:12 -0500
Received: from mx15a.corp.emc.com ([169.254.1.74]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 21 Feb 2013 05:19:11 -0500
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: "mile@ietf.org" <mile@ietf.org>, "marf@ietf.org" <marf@ietf.org>
Date: Thu, 21 Feb 2013 05:19:11 -0500
Thread-Topic: Including Mail fields in IODEF
Thread-Index: AQHOEBvuagQSHFBhb0e+qysbcbjrmQ==
Message-ID: <F5063677821E3B4F81ACFB7905573F24D6253D5D@MX15A.corp.emc.com>
References: <F5063677821E3B4F81ACFB7905573F24D6253D43@MX15A.corp.emc.com>, <B14C10CA81885B4AAE1954F18457F2AB057004DB6D@MX36A.corp.emc.com>
In-Reply-To: <B14C10CA81885B4AAE1954F18457F2AB057004DB6D@MX36A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [marf] Including Mail fields in IODEF
X-BeenThere: marf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/marf>, <mailto:marf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/marf>
List-Post: <mailto:marf@ietf.org>
List-Help: <mailto:marf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/marf>, <mailto:marf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 10:19:28 -0000

Hello,

Cross posting with MAIL and MARF - 

In MILE related work, I have come across use cases that would like to include DKIM and SPF information in addition to specific mail fields (like the ones Chris lists below).  We would like some help to figure out the best approach.  Should we embed ARF and MARF RFC extensions to accommodate this need or should we look at updating RFC5901?  Both take the approach of including an email message as opposed to using XML to tag each field and allow for this in the data model (in my opinion, that is fine and reduces bloat, but there may be other opinions).

There was a draft published last year (link included below) that includes MARF in an IODE extension.

Thanks,
Kathleen
________________________________________
From: Harrington, Christopher
Sent: Wednesday, February 20, 2013 2:57 PM
To: Moriarty, Kathleen; mile@ietf.org
Subject: RE: Mail fields

I'm for the simplest solution as always. These are the indicator types that
we routinely share. I would use these as a base:

Email address (denoting if it is to or from)
Email Subject
Email attachment name
Email attachment hash
X-Mailer (from header)
Hyperlink in email

It's also very common to share the whole header. Bad guys routinely forge
them and put extra header items that can be used as indicators.  Although
not an indicator sharing the entire email as an .eml or .msg file is also
pretty common.

Thanks,

--Chris


-----Original Message-----
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
Moriarty, Kathleen
Sent: Wednesday, February 20, 2013 2:58 AM
To: mile@ietf.org
Subject: [mile] Mail fields

Hi,

In looking at the updated rfc5070bis and coming across some requests for
handling certain types of exchanges, I am curious to hear how others think
we should handle mail related indicators and incidents.  A couple of
commonly exchanged fields were added into the Record class.  You can still
extend out using RFC5901 and include a full mail message, but if you wanted
to include DKIM or Sender Policy Framework, you need something else.  The
IETF group MARF already solved these issues.

MARF uses the email tags rather than XML and there was a draft that embedded
MARF content into IODEF (contains an example), can be found here:
http://tools.ietf.org/html/draft-vesely-mile-mail-abuse-00

Since mail is already marked and can be parsed, would this be a better
option to use what MARF has already done to solve the question on how to
exchange this data?  Other options would be to update RFC5901 or to extend
IODEF further.  I prefer the use of MARF.  It is already in use by mail
operators, so there is adoption.

Thanks,
Kathleen
_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile