gmane.ietf.marf

FW: Open Source implementation of RID agent available

Moriarty, Kathleen — 2013-05-10T16:24:55

In case there is interest from MARF members, I am forwarding the announcement below.  If folks are interested in testing out ARF inside of IODEF, it could be a useful extension to play with off the implementation.

Thank you,
Kathleen
________________________________________
From: mile-bounces< at >ietf.org [mile-bounces< at >ietf.org] On Behalf Of Moriarty, Kathleen [kathleen.moriarty< at >emc.com]
Sent: Friday, May 10, 2013 11:58 AM
To: mile< at >ietf.org
Subject: [mile] Open Source implementation of RID agent available

Hello,

EMC/RSA is pleased to announce the release of an open source implementation of RFC6545 and RFC6546, RID with a HTTP/TLS transport binding.  The software is available under an MIT license on GitHub and is written in Java.  Instructions and information is available in the code folder/tab of the site.  Contributions are welcome to enhance and extend the code base via the normal GitHub process.

The RID agent has been tested with one other implementation that has been open sourced to test the ability to i

Biggest Fake Conference in Computer Science

2013-04-27T17:41:48

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without

Re: Including Mail fields in IODEF

Moriarty, Kathleen — 2013-03-06T04:57:56

Hi Murray,

I may not have been clear enough in my first message.  I was asking about including ARF to represent any/all mail fields useful in exchanges by including ARF.  The option of using RFC5901 with the full mail message would work as well (as you pointed out).  If ARF has wider adoption, it may make sense to use existing standards and tools to accomplish the task by embedding ARF in IODEF.  The format covers some data type representations not in IODEF, but specific to mail (which makes sense to extend when you get that deep).

Thanks,
Kathleen

From: Murray S. Kucherawy [mailto:superuser< at >gmail.com]
Sent: Sunday, March 03, 2013 10:46 PM
To: Panos Kampanakis (pkampana)
Cc: Moriarty, Kathleen; mile< at >ietf.org; marf< at >ietf.org
Subject: Re: [marf] Including Mail fields in IODEF

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

Re: Including Mail fields in IODEF

Murray S. Kucherawy — 2013-03-04T03:46:26

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< at >cisco.com> wrote:

_______________________________________________
marf mailing list
marf< at >ietf.org
https://www.ietf.org/mailman/listinfo/marf

Re: Including Mail fields in IODEF

Panos Kampanakis (pkampana — 2013-03-03T22:37:01

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< at >example.net&gt;
   To: &lt;Undisclosed Recipients&gt;
   Subject: Earn money
   MIME-Version: 1.0
   Content-type: text/plain
   Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail< at >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< at >gmail.com]
Sent: Sunday, March 03, 2

Re: Including Mail fields in IODEF

John Levine — 2013-03-03T16:25:58

In article <CAL0qLwZxwkcJi7Ej0fU5s8k-xZ=n_4fa0cvVVF05YtQPc3Ndag< at >mail.gmail.com>,
Murray S. Kucherawy <superuser< at >gmail.com> wrote:

You also couldn't recognize a complaint about a misdirected ARF report.  That
sort of overloading of fields usually leads to sadness and regret.


That could do it.  Or if you're going to do that, crack apart the ARF report,
put the feedback-report part in the new element, and the message in the
message element.

R's,
John

Re: Including Mail fields in IODEF

Murray S. Kucherawy — 2013-03-03T09:09:32

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< at >cisco.com> wrote:

_______________________________________________
marf mailing list
marf< at >ietf.org
https://www.ietf.org/mailman/listinfo/marf

Re: Including Mail fields in IODEF

Panos Kampanakis (pkampana — 2013-03-01T21:52:31

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< at >ietf.org [mailto:mile-bounces< at >ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Thursday, February 21, 2013 5:19 AM
To: mile< at >ietf.org; marf< at >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 reduc

Re: Including Mail fields in IODEF

Murray S. Kucherawy — 2013-03-03T09:00:16

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 actua

Re: Including Mail fields in IODEF

Alessandro Vesely — 2013-02-24T13:56:43

Hi Kathleen,

On Thu 21/Feb/2013 11:19:11 +0100 Moriarty, Kathleen wrote:

Hey, I never realized that meaning of pronouncing "mile", otherwise I
wouldn't have unsubscribed :-)


Yeah, that slavishly translated and ARF mail into XML.  Its only
practical trait is to represent header fields with a lowercase name,
for example:

 <arf:Field name="x-mailer">QUALCOMM Windows Eudora</arf:Field>

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.

Re: Including Mail fields in IODEF

Shmuel Metz — 2013-02-22T13:30:41

In <F5063677821E3B4F81ACFB7905573F24D6253D5D< at >MX15A.corp.emc.com>, on
02/21/2013
   at 05:19 AM, "Moriarty, Kathleen" <kathleen.moriarty< at >emc.com> said:


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.

Including Mail fields in IODEF

Moriarty, Kathleen — 2013-02-21T10:19:11

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< at >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:

Re: IANA Modifier Names registry

Murray S. Kucherawy — 2012-06-26T20:00:24

I imagine if IANA doesn't do that on its own in the next couple of days,
someone should drop them a note.

-MSK
_______________________________________________
marf mailing list
marf< at >ietf.org
https://www.ietf.org/mailman/listinfo/marf

IANA Modifier Names registry

SM — 2012-06-26T18:25:23

Hi Murray,

I noticed that the IANA Modifier Names (SPF) registry references 
draft-ietf-marf-spf-reporting-10.  Shouldn't that be updated to RFC 6652?

Regards,
-sm

WG Action: Conclusion of Messaging Abuse Reporting Format(marf)

IESG Secretary — 2012-06-26T17:06:38

The Messaging Abuse Reporting Format (marf) Working Group in the 
Applications Area has concluded. The IESG contact persons are Barry 
Leiba and Pete Resnick.

The RFC Editor has published the final MARF documents, and the working
group has finished its work and is now closing. The Applications ADs
thank the anti-abuse community for its work in producing Abuse
Reporting Format standards and related information. Special
posthumous thanks go to the late JD Falk, who worked on his
contributions through periods of hospitalization.

The mailing list <marf< at >ietf.org> will remain open for related discussions.

RFC 6650 on Creation and Use of Email Feedback Reports: AnApplicability Statement for the Abuse Reporting Format (ARF)

2012-06-25T17:31:45

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6650

        Title:      Creation and Use of Email 
                    Feedback Reports: An Applicability Statement for 
                    the Abuse Reporting Format (ARF) 
        Author:     J. Falk, M. Kucherawy, Ed.
        Status:     Standards Track
        Stream:     IETF
        Date:       June 2012
        Mailbox:    none, 
                    superuser< at >gmail.com
        Pages:      15
        Characters: 35273
        Updates:    RFC5965

        I-D Tag:    draft-ietf-marf-as-16.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6650.txt

RFC 5965 defines an extensible, machine-readable format intended for
mail operators to report feedback about received email to other
parties.  This applicability statement describes common methods for
utilizing this format for reporting both abuse and authentication
failure events.  Mailbox Providers of any size, mail-sending
entities, and end users can use t

SPF's helo identity as a reporting target

Alessandro Vesely — 2012-05-08T10:56:10

Hi all,

someone on the spf-discuss list noted that the smtp.helo is often of a
different type than the domains usually branded in smtp.mailfrom,
header.from, and dkim.d.  That's because it seems to be quite common
to outsource mail relaying as well as MX services.  This situation
characterizes relaying services as third parties that might manage
complaints and/or enforce policies, much like ESPs and ISPs.

MARF-AS generically allows any "domain that has been verified by the
[relevant] authentication mechanism", as well as "Abuse addresses in
WHOIS records of the IP address".

Would it be feasible to correlate auth methods' properties to roles,
in general?  For example, ESPs normally wouldn't outsource mail
relaying, since it's their core business.  Thus, sending a complaint
to abuse< at >_smtp.helo_ could be a way to target any involved ESP.

Just mumbling...

Protocol Action: 'Creation and Use of Email FeedbackReports: AnApplicability Statement for the Abuse ReportingFormat (ARF)'to Proposed Standard (draft-ietf-marf-as-16.txt)

The IESG — 2012-04-30T18:03:48

The IESG has approved the following document:
- 'Creation and Use of Email Feedback Reports: An Applicability Statement
   for the Abuse Reporting Format (ARF)'
  (draft-ietf-marf-as-16.txt) as a Proposed Standard

This document is the product of the Messaging Abuse Reporting Format
Working Group.

The IESG contact persons are Pete Resnick and Barry Leiba.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-marf-as/




Technical Summary 

RFC 5965 defines an extensible, machine-readable format intended for 
mail operators to report feedback about received email to other 
parties. This Applicability Statement describes common methods for 
utilizing this format for reporting both abuse and authentication 
failure events. Mailbox Providers of any size, mail sending 
entities, and end users can use these methods as a basis to create 
procedures that best suit them. Some related optional mechanisms are 
also discussed. 

Working Group Summary 

The primary contention point in the develop

Re: Reviewers for draft-kucherawy-marf-source-ports

Douglas Otis — 2012-04-27T18:24:46

Dear Murray,

LSNs or CGNs headed in the direction of using NAT-PMP.

See http://miniupnp.free.fr/nat-pmp.html for a general description.
http://tools.ietf.org/html/draft-cheshire-nat-pmp-03
http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05
Note: REQ-13: A CGN SHOULD NOT log destination addresses or ports.

Also see:
http://tools.ietf.org/html/draft-ietf-pcp-base-24#section-11.5

The significant difference from UPnP is NAT-PMP scheme is resource 
driven rather than being based upon uninformed (scanning) requests.  In 
addition, resources can be reassigned as needed.  Both of these features 
better suit LSN or CGN efforts, especially when port resources are being 
shared across perhaps hundreds of separately sourced transactions.  
Also, such use is likely to be the fault of recipients failing to 
provide IPv6 connectivity causing access providers to employ a large 
scale NAT solution.   NAT-PMP is able to inform the client of both the 
translated port mapping as well as what is the current ext

Re: Final MARF document approved

Murray S. Kucherawy — 2012-04-27T17:37:34

A +1 from me as well.  There was a lot of work put into the six documents we produced.


+1e+06


And thanks for mentoring me through my first co-chairing experience!  You made it fun.

I think MARF had a few challenges but was mostly smooth sailing thanks to all our contributors.  I'll be taking what I learned from this experience into APPSAWG and (with any luck) WEIRDS.  Hope to see you all in there.

-MSK

Final MARF document approved

Barry Leiba — 2012-04-27T17:06:09

The official announcement will go out on Monday, but the final MARF
document, draft-ietf-marf-as, was approved on yesterday's IESG
telechat.  The working group will stay open until the three documents
that are pending (draft-ietf-marf-as, draft-ietf-marf-dkim-reporting,
and draft-ietf-marf-spf-reporting) leave the RFC Editor and get
published as RFCs (in case we should need to have further discussion
during the final RFC Editor processing, which sometimes happens).  But
we can pretty much say that our work here is done.

Thank you all for your valuable contributions and for getting the
documents finished well.  And two special thanks:

A posthumous thanks to JD Falk.  JD did great work with us, with
MAAWG, and with the industry in general.  And he was a good friend,
and a great guy to know.

And to Murray: thanks for being an exceptional co-chair!  This was
Murray's first chair position, and he started excellently and only got
better.  Thanks for taking more than your share of the workload and
making this a