Re: [marf] Including Mail fields in IODEF

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C913F21F84AF; Sun, 3 Mar 2013 01:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8IsCdxrgUrpK; Sun, 3 Mar 2013 01:00:17 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22a]) by (Postfix) with ESMTP id 52C0321F84DC; Sun, 3 Mar 2013 01:00:17 -0800 (PST)
Received: by with SMTP id 12so816524wgh.3 for <multiple recipients>; Sun, 03 Mar 2013 01:00:16 -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=20v0v+mv6OI7TEaWx4IlhmnUfpxU9HUYAzwGo4FB1XI=; b=ak2AiWFEgeoxbGiFN+fu3Ue1NSQNKeMPj4bI9jFSrfxj6RqAGAWGVyZYjGSr6URRij RNBsEm+wFUqHML0gG6w3bl3s9YPCxfSsvx75N6t1if916BtRuoUNnFKr7X0+aoQa6qHN T/174n/vISGIZzxivYZ7nu8m25mDANmnW6ZHkaIk4oGK/QXsEKYJMjTwrk+yQKTlt04B d0gLt3IeAOsDAlo/qX76yJ7GD9L3rUyfk0jPuTe3/Tt2aXpu/+Rc/KC5VwvA1onzTeAA 8ZgTuRKiJCIfpSRgOEb/yQ0S02MeoJSr2Uq8Abzns+vz8qVcnEOSAzG3epCFWkalAxIe Ky/w==
MIME-Version: 1.0
X-Received: by with SMTP id cv8mr5902767wib.5.1362301216380; Sun, 03 Mar 2013 01:00:16 -0800 (PST)
Received: by with HTTP; Sun, 3 Mar 2013 01:00:16 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Sun, 3 Mar 2013 01:00:16 -0800
Message-ID: <>
From: "Murray S. Kucherawy" <>
To: "Moriarty, Kathleen" <>
Content-Type: multipart/alternative; boundary=f46d043c7fba145e9204d70178df
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:00:19 -0000

Hi Kathleen, sorry for the delay replying to this.  It seems to me that, as
you suggested, your options are:

1) As I read RFC5901, it's a set of XML tags used to extract specific
pieces of message data or meta-data and include them in an IODEF report.
You could simply add some DKIM and SPF fields as well.  Keep in mind that
SPF applies once per message (because there's always exactly one envelope)
but any number of DKIM results (including zero) can be present.  There's
also some religion around whether a failed DKIM signature is even worth
reporting, but we can get into that separately if needed.

2) RFC5901 also adds the capability to include a complete email message in
the report payload.  This could be an ARF message (using the SPF and DKIM
extensions), which itself can contain the original.

I would suggest going with (1) personally; it's more work procedurally, but
the result is cleaner.  With (2) you're able to capitalize on what MARF
did, but the receiver has to know that the payload message is actually an
abuse report that contains part or all of the problem message, and is not
itself the problem message.

Let me know if you'd like more detail on any of that.


On Thu, Feb 21, 2013 at 2:19 AM, Moriarty, Kathleen <>; wrote:

> 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
> _______________________________________________
> marf mailing list