One document matched: draft-ietf-repute-email-identifiers-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->

<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="4" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" docName="draft-ietf-repute-email-identifiers-00"
     ipr="trust200902">

<front>

 <title abbrev="Email Identities Reputation Vocabulary">
	A Reputation Vocabulary for Email Identities
 </title>

 <author fullname="Nathaniel Borenstein" initials="N." surname="Borenstein">
  <organization>Mimecast</organization>
  <address>
   <postal>
    <street>203 Crescent St., Suite 303</street>
    <city>Waltham</city>
    <region>MA</region>
    <code>02453</code>
    <country>USA</country>
   </postal>
   <phone>+1 781 996 5340</phone>
   <email>nsb@guppylake.com</email>
  </address>
 </author>
    
 <author fullname="Murray S. Kucherawy" initials="M. S." surname="Kucherawy">
  <organization>Cloudmark</organization>
  <address>
   <postal>
    <street>128 King St., 2nd Floor</street>
    <city>San Francisco</city>
    <region>CA</region>
    <code>94107</code>
    <country>USA</country>
   </postal>
   <phone>+1 415 946 3800</phone>
   <email>msk@cloudmark.com</email>
  </address>
 </author>
    
 <date year="2011" />

 <area>Applications</area>
 <workgroup>REPUTE Working Group</workgroup>

 <keyword>reputation</keyword>
 <keyword>domain</keyword>
 <keyword>security</keyword>
 <keyword>messaging</keyword>
 <keyword>dkim</keyword>
 <keyword>spf</keyword>
 <keyword>authentication</keyword>

 <abstract>
  <t> This document defines a vocabulary for describing email identities
      (typically authors or signers) with the application/reputon media
      type. </t>
 </abstract>
</front>

<middle>
 <section title="Introduction">
  <t> This memo defines a "vocabulary" for describing reputation of an
      email identity.  A "vocabulary" in this context is defined in
      [RFCxxxx] and is used to describe assertions a reputation service
      provider can make about email identities as well as meta-data that
      can be included in such a reply beyond the base set specified there. </t>
 </section> <!-- Introduction -->

 <section title="Terminology and Definitions" anchor="terms_and_defs">
  <t>This section defines terms used in the rest of the document.</t>

  <section title="Keywords" anchor="defs_keywords">
   <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in
      <xref target="KEYWORDS"/>.</t>
  </section> <!-- Keywords -->

  <section title="Email Definitions" anchor="defs_email">
   <t> Commonly used definitions describing entities in the email architecture
       are defined and discussed in <xref target="EMAIL-ARCH"/>. </t>
  </section> <!-- Email Definitions -->

  <section title="Other Definitions" anchor="defs_other">
   <t> Other terms of importance in this memo are defined in RFCxxxx, the
       base memo in this document series. </t>
  </section> <!-- Other Definitions -->
 </section> <!-- Terminology and Definitions -->

 <section title="Discussion" anchor="discussion">
  <t> The expression of reputation about an email identity requires
      extensions of the base set defined in [RFCxxxx].  This memo
      defines and registers some common assertions about
      an entity found in a piece of <xref target="MAIL"/>. </t>

  <section title="Assertions" anchor="assertions">
   <t> The "email-id" reputation application recognizes the following
       assertions:

	<list style="hanging">
		<t hangText="PERPETRATES-FRAUD:"> The subject identity is
			associated with fraudulent email </t>

		<t hangText="SENDS-MALWARE:"> The subject identity is
			associated with the sending or relaying of
			malware via email </t>

		<t hangText="SENDS-SPAM:"> The subject identity is associated
			with unwanted bulk email </t>

		<t hangText="SENDS-TO-INVALID-RECIPIENTS:"> The subject
			delivery attempts to nonexistent recipients </t>
	</list> </t>

    <t> For all assertions, the RATING scale is linear: A value of 0.0 means
        there is no data to support the assertion, a value of 1.0 means all
        accumulated data support the assertion, and the intervening values
        have a linear relationship (i.e., a score of "x" is twice as strong
        of an assertion as a value of "x/2"). </t>
  </section> <!-- Assertions -->

  <section title="Vocabulary Extensions" anchor="vocabulary">
   <t> The "email-id" reputation application recognizes the following
       OPTIONAL extensions to the vocabulary defined in [RFCxxxx]:

	<list style="hanging">
		<t hangText="IDENTITY:"> A token indicating the source of
			the identity; that is, where the subject identity
			was found in the message.  This MUST be one of:

			<list style="hanging">
				<t hangText="DKIM:"> The signing domain, i.e.
					the value of the "d=" tag, found
					on a valid <xref target="DKIM"/>
					signature in the message </t>

				<t hangText="IPV4:"> The IPv4 address of
					the client </t>

				<t hangText="IPV6:"> The IPv6 address of
					the client </t>

				<t hangText="RFC5321.MAILFROM:"> The
					RFC5321.MailFrom value of the envelope
					of a message of the message
					(see <xref target="SMTP"/>) </t>

				<t hangText="RFC5322.FROM:"> The RFC5322.From
					field of the message (see
					<xref target="MAIL"/>) </t>

				<t hangText="SPF:"> The identity verified by
					<xref target="SPF"/>) </t>
			</list> </t>

		<t hangText="RATE:"> A token that recommends an overall
			message acceptance rate for the subject domain.
			This is expected to be a value tailored to the
			requesting agent; for example, the reputation service
			would use this to indicate that, based on the
			data reported by the requesting agent, the service
			recommends a particular message limit for that
			agent.  The value is an unsigned decimal value. </t>

		<t hangText="SOURCES:"> A token relating a count of the
			number of sources of data that contributed to
			the reported reputation.  This is in contrast to
			the SAMPLE-SIZE parameter, which indicates the
			total number of reports across all reporting
			sources. </t>
	</list> </t>

   <t> A reply that does not contain the IDENTITY or SOURCES extensions is
       making a non-specific statement about how the reputation returned
       was developed.  A client may use or ignore such a reply at its
       discretion. </t>
  </section> <!-- Vocabulary Extensions -->
 </section> <!-- Discussion -->

 <section title="IANA Considerations" anchor="iana_considerations">
  <t> This memo presents one action for IANA, namely the registraton of
      the reputation application "email-id". </t>

  <section title="Registration of 'email-id' Reputation Application"
           anchor="iana_reg">
   <t> This section registers the "email-id" reputation application, as
       defined in [RFCxxxx+1].  The registration parameters are as
       folows: 

	<list style="symbols">
	 <t> Application name: email-id </t>

	 <t> Short description: Evaluates DNS domain names found in email
	     identities </t>

	 <t> Defining document: [this memo] </t>

	 <t> Status: current </t>

	 <t> Application-specific query parameters:
		<list style="hanging">
			<t hangText="subject:"> (current)
				identifies the subject of the reputation
				query; in this case, it is the email identity
				whose reputation is requested </t>
		</list> </t>
	</list> </t>
  </section> <!-- Registration of 'email-id' Reputation Application -->
 </section> <!-- IANA Considerations -->

 <section title="Security Considerations" anchor="sec_considerations">
  <t> This memo describes security considerations introduced by the reputation
      application and vocabulary defined here. </t>

  <t> [TBD] </t>
 </section> <!-- Security Considerations -->
</middle>

<back>
 <references title="Informative References">
	<reference anchor="DKIM">
		<front>
			<title>
				DomainKeys Identified Mail (DKIM)
				Signatures
			</title>

			<author initials="D." surname="Crocker"
			        fullname="D. Crocker" role="editor">
				<organization>
					Brandenburg InternetWorking
				</organization>
			</author>

			<author initials="T." surname="Hansen"
			        fullname="T. Hansen" role="editor">
				<organization>
					AT&T Laboratories
				</organization>
			</author>

			<author initials="M." surname="Kucherawy"
			        fullname="M. Kucherawy" role="editor">
				<organization>
					Cloudmark
				</organization>
			</author>

			<date year="2011" month="September"/>
		</front>

		<seriesInfo name="RFC" value="6376"/>
	</reference>

	<reference anchor="EMAIL-ARCH">
		<front>
			<title> Internet Mail Architecture </title>
			<author initials="D." surname="Crocker"
			        fullname="D. Crocker">
				<organization>
					Brandenburg InternetWorking
				</organization>
			</author>
			<date month="July" year="2009" />
		</front>
		<seriesInfo name="RFC" value="5598" />
	</reference>

	<reference anchor="KEYWORDS">
		<front>
			<title abbrev="RFC Key Words">Key words for
			       use in RFCs to Indicate Requirement
			       Levels</title>

			<author initials="S." surname="Bradner"
			        fullname="Scott Bradner">
				<organization>Harvard University</organization>
			</author>

			<date year="1997" month="March"/>
		</front>

		<seriesInfo name="BCP" value="14"/>
		<seriesInfo name="RFC" value="2119"/>
	</reference>

	<reference anchor="MAIL">
		<front>
			<title> Internet Message Format </title>
			<author initials="P." surname="Resnick"
				fullname="P. Resnick" role="editor">
				<organization>
					Qualcomm, Inc.
				</organization>
			</author>
			<date month="October" year="2008" />
		</front>
		<seriesInfo name="RFC" value="5322" />
	</reference>

	<reference anchor="SMTP">
		<front>
			<title>Simple Mail Transfer Protocol</title>

			<author initials="J." surname="Klensin"
			        fullname="J. Klensin">
				<organization/>
			</author>

			<date year="2008" month="October"/>

		</front>

		<seriesInfo name="RFC" value="5321"/>
	</reference>

	<reference anchor="SPF">
		<front>
			<title>
				Sender Policy Framework (SPF) for
				Authorizing Use of Domains in E-Mail,
				Version 1
			</title>
			<author initials="M." surname="Wong"
			        fullname="M. Wong">
				<organization/>
			</author>
			<author initials="W." surname="Schlitt"
			        fullname="W. Schlitt">
				<organization/>
			</author>
			<date year="2006" month="April"/>
		</front>
		<seriesInfo name="RFC" value="4408"/>
	</reference>
 </references>

 <section title="Acknowledgments" anchor="acks">
  <t> The authors wish to acknowledge the contributions of the following to
      this specification:
      John Levine,
      and
      David F. Skoll. </t>
 </section>

 <section title="Public Discussion" anchor="public">
  <t> Public discussion of this suite of memos takes place on the
      domainrep@ietf.org mailing list.  See
      https://www.ietf.org/mailman/listinfo/domainrep. </t>
 </section>
</back>
</rfc>