Network Working GroupJ. Macdonald
Internet Drafte-Dialog
<macdonald-affiliated-nameslist-00-04dc (pre-release)> D. Crocker
Intended status: InformationalBrandenburg InternetWorking
Expires: July 2009January 27, 2009

Affiliations List (AffiL)
macdonald-affiliated-nameslist-00-04dc (pre-release)

Status of this Memo


Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.

The list of current Internet-Drafts can be accessed at <>.

The list of Internet-Draft Shadow Directories can be accessed at <>.

This Internet-Draft will expire in July 2009.


Domain names can be used as the core identifier in an assessment process, such as when filtering incoming email. One type of assessment is to note that the name is used by a person, role or organization having a particular affiliation, such as being part of a well-known company or being part of a salient industry association. Such a list is distinct from qualitative assessment lists, such as for email reputation. This specification provides a method for determining whether an individual, authenticated domain name has a particular affiliation. It provides a means by which the list owner can describe the list, but the specification does not indicate what affiliations exist or should be consulted. The specification uses Vouch By Reference (VBR) as its query mechanism.

Table of Contents

1. Introduction

Organizations are often referenced on the Internet in terms of their registered domain names. It can be helpful to determine whether a particular name is affiliated with a particular organization or, in turn, whether a particular organization itself has an "interesting" affiliation with some other organization, group or activity. The ability to discern these affiliations can provide useful input to an assessment process, such as for filtering inbound email. Affiliation is distinct from reputation, in that it is an objective statement about a relationship, rather than a more subjective statement about quality. Typically, an affiliation list merely documents an existing relationship, whereas quality assessment statements are the result of incremental and subjective work by the publisher. Hence, affiliations are more easily documented. In terms of using the publication information for performing decision-making by the consumer, the utility of an affiliations list is based on having the consumer of the list perform the quality assessment step, rather than the publisher.

Many different types of affiliation lists are possible. They can declare ownership by the publisher, some sort of permission by the publisher, membership in a group, and so on. Examples include:

This specification defines a method by which organizations can publish these affiliations in an online list, so as to permit easy verification. The means by which a potential user of a list learns of its existence and then decides to query it is outside the scope of this specification. It is a distributed, open process, much like discovering and deciding to use email addresses or web addresses.

Conventions used in this specification are defined by:

Terminology conforms to [].
Formal Notation:
Formal syntax definitions use ABNF [RFC2434]. Inline references to ABNF rules are distinguished by surrounding <...> brackets. References to formally-defined commands or fields are marked by a two-part notation, first listing the specification and then listing the command or field, in the form: specification.command-field. As a shorthand, references to fields within the RFC5322 header use a Fieldname: notation.
Normative Language:
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 [RFC2119].

Public discussion of this draft should be conducted on the mailing list.
NOTE TO RFC EDITOR:   This "Discussion" text is to be removed prior to publication.

2. Affiliations List Model

A list declares affiliation for a set of names, that is, association to the group or activity for which the list is published. It carries no additional semantics beyond the claim of membership. For example it does not suggest that a member of the list is a Good Actor or a Bad Actor in their email interactions with the consumer of the list. Lists can be self-published, by the owner of the listed names -- self-listed publication -- or by a different organization -- independent publication. The list is published by the list owner, so that presence on the list is self-authenticating and self-certifying. The list owner separately publishes an Affiliation Description which specifies the list's criteria for membership and provides any details for attributes encoded into a list entry.

A list is accessible via a domain name that is called the List Name. The owner of that domain name is called the List Owner.

The decision to consult a particular list is made in two stages. The first stage occurs long before the list is consulted and is performed as an administrative act. It is a strategic, deliberative activity that decides what lists are to be enabled for consultation.

List publishers need to carefully consider the value proposition and usage cost for the list, as they will be assessed by potential queriers, since these are likely to be the primary factors in their deciding whether to enable list consultation. A challenging aspect of this exercise, for list publishers, is to assume that there will be many such lists, produced by many publishers, and that the aggregate cost of consulting many lists is expensive. Hence the value-proposition for a particular list needs to be distinctive.

The second stage occurs as part of regular, in-line operations, at the time lists are consulted. It is determined by immediate details of operation, such as the content or attributes of a received email.

When a list is queried, the primary result MUST be a binary statement of list membership: Is the queried domain in the queried list? The query MAY also produce related, parametric information about the queried domain.

AffiL uses Vouch By Reference (VBR) [I-D.VBR] as its query mechanism. As currently specified, VBR is defined for use by independent parties to certify a set of domain name owners that are associated with received mail. However, the mechanism equally can support publication by the owner of listed names. That is, it permits an organization to self-list a set of domain names. AffiL treats the cases of Self-Listing and Independent Listing as equivalent and the differences between the two are outside the cope of AffiL, but of course can be an important factor in a potential querier's decision about whether to consult a particular list.

3. AffiL List Description

Prior to consulting a particular list, a potential querier decides that this list is (sometimes) worthy of consultation. They decide to configure their run-time software to include the list for queries under specified conditions that the querier can envision. There are many different ways by which a potential querier might learn about the existence of a list and the details for it.

To assist such discovery efforts, the publisher MAY provide a web page that describes the list and specifies any special syntax and semantics for it. This section defines a standard format for such a description of an Affiliations List.

A list description comprises:

Domain Name of list:
This specifies the location in the DNS at which the list can be found.
Descriptive Name of List:
This provides a human-friendly label for referencing the list
Type of List:
In order to facilitate a queriers' consideration of what lists to use, this provides a registered label that describes the common semantics of the list. {{ IANA Registration required }}
Revision date for list description:
This supports basic version control.
Name of person, role, brand or organization publishing the list:
This provides the human-friendly common label for the list owner.
Textual description of the list:
This is a free-form explanation of the nature and purpose for this list.
One or more list entries, comprising:
  • Domain name
  • Name of affiliated organization
  • List-specific attributes, such as type of membership, duration of membership, security policies for organization.

3.1 List Description Syntax:


3.2 List Description Location

(Where is a List Description located?)


4. Query Name Selection

Content, such as email, typically contains many name references. Any of these might be a candidate as the name to use for an AffiL query. The choice is determined by the semantics of the list to be queried. If the VBR-Info tag is present, the md= can suggest the choice; other tags within the header field can indicate further query constraints.

5. Consulting a List

A module that is performing assessments is likely to have a range of lists available for consulting. The first task, then, is to decide which to query. The factors that determine the choices will vary. For email, the presence of specific identifiers or specific types of identifiers will be important. For example, the rfc5322.From field might contain a well-known domain name that is often spoofed, or a validated identifier for message responsibility might need to be assessed.

As input to the decision process the data being evaluated MAY itself offer hints. For example, VBR is tailored for use with email and permits a message to contain a VBR-Info: header field. The field contains advice from the message creator. This advice is only a suggestion about lists to consult and MUST NOT be taken as confirming the affiliation that is claimed. That is, it can only be used as a hint by a possible list member about which lists should be consulted. Validation of affiliation can only be obtained by performing the query and queries SHOULD only be made of lists already vetted by the querier.

6. Using a List Entry

The primary semantic result of an AffiL query is a binary assessment about affiliation with a particular list. This assessment is then communicated to an external modules, such as an email Handling Filter that determines whether to deliver a message.

7. Examples

7.1 Member of an Industry Organization

The mere fact that a person or organization is a member of a particular group can sometimes be useful in making an assessment. For example, if a message purports to be from a bank, evaluating that claim can benefit from being able to determine whether any domain names that it cites do, indeed, belong to a bank. One indication of status for the organization owning the cited domain name would be membership in a banking association.

This scenario in that the list owner is independent of the domain name owner(s), except for the relationship asserted through publication of the list.

List Description:

Domain Name of list:
Descriptive Name of List:
List of the Banking Association Member Organizations
Type of List:
Revision date for list description:
22 Jan 2009
Name of person, role, brand or organization publishing the list:
The Banking Association
Textual description of the list:
The Banking Association preserves and promotes public confidence in the financial system by insuring deposits in banks and thrift institutions. This list specifies domain names used formally by banks that have membership in The Banking Association.
One or more list entries, comprising:
  • Domain name
  • Official name of member bank
  • List-specific attributes: None
For example:
  • local-bank.example
  • The Local Bank

7.2 Domains Owned by Publisher

A company, conglomerate.example, sells many different products, under many different brand names. Some of these brands are spoofed, including by the use of look-alike domain names. The company wishes to list the set of domain names that actually are affiliated with conglomerate.example. One use of this would be for an anti-abuse filtering engine to detect when a message as purports to be from the company. Consulting the conglomerate.example list could determine whether the validated domain name(s) being used with the message are, in fact, used by the company

This example is distinctive in that the list owner is the same as the owner of the listed domain names.

List Description:

Domain Name of list:
Descriptive Name of List:
Domain names for different brands belonging to The Conglomerate Company.
Type of List:
Revision date for list description:
22 Jan 2009
Name of person, role, brand or organization publishing the list:
The Conglomerate Company
Textual description of the list:
Each of the listed domain names is owned by The Conglomerate Company and is used to differentiate among different product and service brands used by the company.
One or more list entries, comprising:
  • Domain name
  • Name of our brand
  • List-specific attributes: None
For example:
  • The Conglomerate Company, Brand-A

7.3 Authorized Agents of the Email Author's Domain

Organizations often outsourced their email processing, such as for sending large blocks of subscription-based email to customers. Such an Email Service Provider (ESP) is an authorized agent of the organization. However the ESP's own domain names have no obvious relationship to the authorizing organization. For some scenarios, it is decided to have authenticated domain names that are associated with messages be those of the ESP. The desire, then, is to permit the authorizing organization to declare that the ESP is an authorized agent for sending messages on behalf of the organization.

This scenario can appear to be similar to a membership listing. However it is distinctive in that the list owner is indicated through the content of the message -- notably including the author identifier, such as the From: field. Further, by virtue of declaring that the listed domains are acting as agents of the list owner, its semantics indicate an explicit degree of trust that the list owner is declaring for the listed domains.

List Description:

Domain Name of list: authorizingco.example
Descriptive Name of List: Authorized Email Agent Names
Type of List:
Revision date for list description:
22 Jan 2009
Name of person, role, brand or organization publishing the list:
The Authorizing Company
Textual description of the list:
This list declares domain names for organizations that are authorized to send mail on behalf of The Authorizing Company.
One or more list entries, comprising:
  • domain name
  • Name of authorized company
  • List-specific attributes: none
For example:
  • authorizingco.esp.example
  • The ESP Company

8. Security Considerations

***** All drafts are required to have a security considerations section. *****

9. References

9.1 References -- Normative

[I-D.VBR]Hoffman, P., Levine, K., and A. Hathcock, “Vouch By Reference (VBR)”, ID draft-hoffman-dac-vbr, December 2008.
[RFC2119]Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2434]Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, RFC 2434, October 1998.

9.2 References -- Informative

[]Crocker, D., “Internet Mail Architecture”, Feb 2008.

Authors' Addresses

Jeff Macdonalde-Dialog131 Hartwell AvenueLexington, MA 01432USAPhone: 781-372-1922EMail:
Dave CrockerBrandenburg InternetWorking675 Spruce Dr.Sunnyvale, CA 94086USAEMail:

A. IANA Considerations

A.1 AffiL Type of List Registration Details

*** Procedures for registering a "type of list" label ***

B. Acknowledgements

*** Acknowledgements ***

Full Copyright Statement

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.


Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at <>.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at