Re: [marf] Including Mail fields in IODEF

"Murray S. Kucherawy" <> Sun, 03 March 2013 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A1DC21F8648; Sun, 3 Mar 2013 01:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.117
X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HsdrMkLMPFTg; Sun, 3 Mar 2013 01:09:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 97A9A21F85EE; Sun, 3 Mar 2013 01:09:33 -0800 (PST)
Received: by with SMTP id dr13so3442250wgb.26 for <multiple recipients>; Sun, 03 Mar 2013 01:09:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uF1tTBOit/eOXcG0zSoqhIq3LEc7i5Im8bBhw5oTpLY=; b=cRMMteOcFghHnLXzOeANcM/1QLap7HjK3bxQdzqAh6NlOaRMJ2ZbXL4lAYS5jjnvMs tPlvi/4gQ83hx8zSmlEIQ9FWYjytpsyPkpKrlFKzk4DS/ChEadLcPLrNY9pnwkMTTnxx sRk30Daecy0BpjpnpUXZ0KehOqCFaE4qK8sQvD6dSnnWRk26McyrY1jEF2fUdVFzK68X iBCJV06NFo4YGpVRPhCEYfHsRuLOxhSFx55QcF4fY4bqR9N56LF4fY2yt/u4fxRthQW0 6DZhI5FeerpV0s0EN93UBQaGp329hG6CL9bdLlUJmrinTZd3wRxBnH0c/ooWXF39ur5L et/g==
MIME-Version: 1.0
X-Received: by with SMTP id g6mr5415567wiy.21.1362301772581; Sun, 03 Mar 2013 01:09:32 -0800 (PST)
Received: by with HTTP; Sun, 3 Mar 2013 01:09:32 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 3 Mar 2013 01:09:32 -0800
Message-ID: <>
From: "Murray S. Kucherawy" <>
To: "Panos Kampanakis (pkampana)" <>
Content-Type: multipart/alternative; boundary=f46d044267263b52da04d701991a
Cc: "" <>, "" <>
Subject: Re: [marf] Including Mail fields in IODEF
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Mar 2013 09:09:36 -0000

The issue with MARF inside IODEF is that the receiver needs to know that
the payload being provided inside an EmailMessage element is itself an ARF
report, and not the message that caused the report in the first place.  You
certainly could crack open the EmailMessage content and see if conforms to
the ARF specification to tell which kind of report you've gotten, but that
seems inelegant.

I suppose then another option is an extension element that indicates you've
received an ARF payload rather than the actual offending message.

Also of note: An ARF can contain the offending message or only the
offending message's header, and still be compliant.  If your application
needs the whole message, you'll have to add some additional stipulations


On Fri, Mar 1, 2013 at 1:52 PM, Panos Kampanakis (pkampana) <>; wrote:

> I think MARF provides more functionality and should be leverage for emails
> in IODEF.
> I also think we need to resurrect
> within MILE
> since MARF was concluded..
> Panos
> -----Original Message-----
> From: [] On Behalf Of
> Moriarty, Kathleen
> Sent: Thursday, February 21, 2013 5:19 AM
> To:;
> Subject: [mile] Including Mail fields in IODEF
> 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;
> 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: [] On Behalf Of
> Moriarty, Kathleen
> Sent: Wednesday, February 20, 2013 2:58 AM
> To:
> 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:
> 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 mailing list
> _______________________________________________
> marf mailing list