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: <[email protected]>
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: [email protected]
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:[email protected]]
Sent: Sunday, March 03, 2013 4:10 AM
To: Panos Kampanakis (pkampana)
Cc: Moriarty, Kathleen; [email protected]; [email protected]
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)
<[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of
Moriarty, Kathleen
Sent: Thursday, February 21, 2013 5:19 AM
To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
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; [email protected]<mailto:[email protected]>
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: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of
Moriarty, Kathleen
Sent: Wednesday, February 20, 2013 2:58 AM
To: [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mile
_______________________________________________
mile mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mile
_______________________________________________
marf mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/marf
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
