Re: [marf] Including Mail fields in IODEF

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 04 March 2013 03:46 UTC

Return-Path: <superuser@gmail.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 0472021F886D; Sun, 3 Mar 2013 19:46:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 qCkQnp-KJpXf; Sun, 3 Mar 2013 19:46:33 -0800 (PST)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3F121F8717; Sun, 3 Mar 2013 19:46:26 -0800 (PST)
Received: by mail-we0-f180.google.com with SMTP id k14so4011522wer.39 for <multiple recipients>; Sun, 03 Mar 2013 19:46:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=naGsKMv8T5swkmprE0gZB7mUzsafJiEzxvyQha/2nEg=; b=eNDXEtGN4UkbiXMaqRTCZPMRouNLGS2ObLOrCLbhQshcyrwdWRGnRbUTkMhIbEli7x bP7azDzNiknfF7OnojUpRnGpIlFgwYZRnp/ZUMfEM+0bYYivnVumxXcekJNB6zqEnu7q BGcxdDjOBQgJv4uDSdf7s5Gj4JKI3IQWe/fJnFJ7C6+0YrK07VtV8mH6Q/1/TgtSjJD3 NUxcR68GK+KOqkMmkZJFdDEFeIMfmCPv6EEolKT8NcmWhpez1VG9IFI8lYykAwJo2t/r Y12gJKHzZi0HjCn7AAjFl7PRcFil3beFam6bSyU0606XQ8Q1ik2NckcAJh3J4NHar/55 1DQA==
MIME-Version: 1.0
X-Received: by 10.180.185.44 with SMTP id ez12mr8295760wic.33.1362368786189; Sun, 03 Mar 2013 19:46:26 -0800 (PST)
Received: by 10.180.189.6 with HTTP; Sun, 3 Mar 2013 19:46:26 -0800 (PST)
In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A75187BDA@xmb-rcd-x10.cisco.com>
References: <F5063677821E3B4F81ACFB7905573F24D6253D43@MX15A.corp.emc.com> <B14C10CA81885B4AAE1954F18457F2AB057004DB6D@MX36A.corp.emc.com> <F5063677821E3B4F81ACFB7905573F24D6253D5D@MX15A.corp.emc.com> <1C9F17D1873AFA47A969C4DD98F98A75187684@xmb-rcd-x10.cisco.com> <CAL0qLwZxwkcJi7Ej0fU5s8k-xZ=n_4fa0cvVVF05YtQPc3Ndag@mail.gmail.com> <1C9F17D1873AFA47A969C4DD98F98A75187BDA@xmb-rcd-x10.cisco.com>
Date: Sun, 3 Mar 2013 19:46:26 -0800
Message-ID: <CAL0qLwaE1pS98kq8XSETMk-kKvCWZnErP3RdKO3CRa5jOXtTnw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
Content-Type: multipart/alternative; boundary=001a11c225748dd5dd04d71133ce
Cc: "mile@ietf.org" <mile@ietf.org>, "marf@ietf.org" <marf@ietf.org>
Subject: Re: [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: Mon, 04 Mar 2013 03:46:38 -0000

Hi Panos,

The "feedback-type" would be part of the ArfHeader object, I would
imagine.  It appears immediately before the portion of the example you
cited.

This might also be a viable way to add ARF capability to IODEF, though I
don't think that was the original problem statement (which was only to
include DKIM and SPF details).

At any rate, I don't think you're reading it wrong.

-MSK


On Sun, Mar 3, 2013 at 2:37 PM, Panos Kampanakis (pkampana) <
pkampana@cisco.com>; wrote:

>  Thank you Murray.****
>
> ** **
>
> The “<arf:EmailMessage>****
>
>    Received: from mailserver.example.net****
>
>         (mailserver.example.net [192.0.2.1])****
>
>         by example.com with ESMTP id M63d4137594e46;****
>
>         Thu, 08 Mar 2005 14:00:00 -0400****
>
>    From: &lt;somespammer@example.net&gt;****
>
>    To: &lt;Undisclosed Recipients&gt;****
>
>    Subject: Earn money****
>
>    MIME-Version: 1.0****
>
>    Content-type: text/plain****
>
>    Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net****
>
>    Date: Thu, 02 Sep 2004 12:31:03 -0500****
>
> ** **
>
>    Spam Spam Spam****
>
>    Spam Spam Spam****
>
>    Spam Spam Spam****
>
>    Spam Spam Spam****
>
>          </arf:EmailMessage>”****
>
> that I see in http://bgp.potaroo.net/ietf/all-ids/draft-vesely-mile-mail-abuse-00.txt looks like just an email message. I don’t see “feedback-type" or other ARF fields for example that would make it a ARF.****
>
> ** **
>
> draft-vesely-mile-mail-abuse-00.txt seems to define a header and then have the option for the actual message (EmailMessage). Am I reading it wrong?****
>
> ** **
>
> Panos****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Murray S. Kucherawy [mailto:superuser@gmail.com]
> *Sent:* Sunday, March 03, 2013 4:10 AM
> *To:* Panos Kampanakis (pkampana)
> *Cc:* Moriarty, Kathleen; mile@ietf.org; marf@ietf.org
> *Subject:* Re: [marf] Including Mail fields in IODEF****
>
> ** **
>
> 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
> someplace.****
>
> -MSK****
>
> ** **
>
> On Fri, Mar 1, 2013 at 1:52 PM, Panos Kampanakis (pkampana) <
> pkampana@cisco.com>; wrote:****
>
> I think MARF provides more functionality and should be leverage for emails
> in IODEF.
> I also think we need to resurrect
> http://tools.ietf.org/html/draft-vesely-mile-mail-abuse-00 within MILE
> since MARF was concluded..
> Panos****
>
>
>
> -----Original Message-----
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
> Moriarty, Kathleen****
>
> Sent: Thursday, February 21, 2013 5:19 AM
> To: mile@ietf.org; marf@ietf.org
> 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; 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
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile
> _______________________________________________
> marf mailing list
> marf@ietf.org
> https://www.ietf.org/mailman/listinfo/marf****
>
> ** **
>