From kathleen.moriarty@emc.com Thu Feb 21 02:19:28 2013 Return-Path: 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" To: "mile@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: References: , In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 10:19:28 -0000 Hello, Cross posting with MAIL and MARF -=20 In MILE related work, I have come across use cases that would like to inclu= de DKIM and SPF information in addition to specific mail fields (like the o= nes Chris lists below). We would like some help to figure out the best app= roach. Should we embed ARF and MARF RFC extensions to accommodate this nee= d or should we look at updating RFC5901? Both take the approach of includi= ng 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 M= ARF 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 embedde= d 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 From shmuel+gen@patriot.net Fri Feb 22 05:27:41 2013 Return-Path: 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 CEF9021F8FCB for ; Fri, 22 Feb 2013 05:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 B1go2huKo3Ci for ; Fri, 22 Feb 2013 05:27:41 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 02CC821F8FCA for ; Fri, 22 Feb 2013 05:27:40 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.116]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 5B1E6F5809C for ; Fri, 22 Feb 2013 08:19:41 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Fri, 22 Feb 2013 08:30:41 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20130222131941.5B1E6F5809C@smtp.patriot.net> Subject: Re: [marf] Including Mail fields in IODEF X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:27:41 -0000 In , on 02/21/2013 at 05:19 AM, "Moriarty, Kathleen" said: >Should we embed ARF and MARF RFC extensions to accommodate this need >or should we look at updating RFC5901? Note that RFC 5965 et al establish IANA registries; those are the preferred mechanism for extensions. Where you need an extension beyond what can be done with the existing registries, you should consider establishing new registries to simplify future extensions beyond what you initially devise. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Sun Feb 24 05:56:46 2013 Return-Path: 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 C8BD321F8FF7; Sun, 24 Feb 2013 05:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.529 X-Spam-Level: X-Spam-Status: No, score=-4.529 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 CQJJ8rU5rhXf; Sun, 24 Feb 2013 05:56:46 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A588221F8FEC; Sun, 24 Feb 2013 05:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1361714203; bh=VZw3M738BwZQh/SHY4AHA7G6ptV2LNHmaohutLVd80o=; l=768; h=Date:From:To:CC:References:In-Reply-To; b=eT59g/M2TeI0gZokgDbcK7TVuWpO9utCG9vRGYLL66uYs0GY0YKDGisYVFyC5HwRJ vK14cvAqWTpwROK7oT31Zr1Eusfiik9ZouFsfXsTru2/MEo2eKRRXWElRqZY4if02p ZN4qCscg6eb8qqRAnXdIhqzp3RxHtfQquWYQRPJ0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sun, 24 Feb 2013 14:56:43 +0100 id 00000000005DC039.00000000512A1C1B.00002764 Message-ID: <512A1C1B.5060802@tana.it> Date: Sun, 24 Feb 2013 14:56:43 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: , In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Managed Incident Lightweight Exchange IODEF extensions and RID exchanges , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 13:56:46 -0000 Hi Kathleen, On Thu 21/Feb/2013 11:19:11 +0100 Moriarty, Kathleen wrote: > > Cross posting with MAIL and MARF - Hey, I never realized that meaning of pronouncing "mile", otherwise I wouldn't have unsubscribed :-) > There was a draft published last year (link included below) that > includes MARF in an IODEF extension. Yeah, that slavishly translated and ARF mail into XML. Its only practical trait is to represent header fields with a lowercase name, for example: QUALCOMM Windows Eudora That kind of thing can be useful to get a value quickly; that is, while parsing the XML. If the alternative is to extract the whole message (or header) and then parse that in turn, it might be worth to have it.