Updated: Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys)
Abstract: «”DomainKeys” creates a domain-level authentication framework for email by using public-key technology and the DNS to prove the provenance and contents of an email.»
«This document defines the base framework of digitally signing email on a per-domain basis. Subsequent documents leverage this base framework to prove and validate email delivery paths as well as extend signing to facilitate per-user authentication.»
«The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today. Proof and protection of email identity may assist in the global control of “spam” and “phishing”.»
«While this document presents technical details, it is not yet intended as a definitive or final specification, rather, the intent is to define a framework and sufficient technical detail to promote experimental deployment with a view to evolving into a comprehensive authentication standard for email.»
Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys) (diff)
New: The Atom Publishing Protocol (Basic)
Abstract: «This memo presents a protocol for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content. »
«The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. The protocol at its core is the HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (draft-ietf-atompub-format-06.txt). »
The Atom Publishing Protocol (Basic)
Updated: Extensible Mail Protocol (ExMP)
Abstract: «This document describes the Extensible Mail Protocol (ExMP); a protocol designed to deliver XML formatted mail messages between post office nodes using Simple Object Access Protocol (SOAP) via HTTPS. The purpose of this ExMP is to become a total end-to-end mail delivery and retrieval system that is both scalable and secure.»
Extensible Mail Protocol (ExMP) (diff)
Updated: Internet Mail Architecture
Abstract: «Over its thirty-four year history, Internet Mail has undergone significant changes in scale and complexity, as it has become a global infrastructure service. The first standardized architecture for email specified a simple split between the user world, in the form of Mail User Agents (MUA), and the transmission world, in the form of the Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). Core aspects of the service, such as address and message style, have remained remarkably constant. Today, Internet Mail is marked by many independent operators, many different components for providing users service and many others for performing message transfer. Public discussion of the architecture has not kept pace with the real-world technical and operational refinements. This document offers an enhanced Internet Mail architecture to reflect the current service.»
Internet Mail Architecture (diff)
Updated: Message Header for Indicating Sender Authentication Status
Abstract: «This memo defines a new message header for use with [MAIL] messages to indicate the results of sender authentication efforts to mail user agents (MUAs) in order to equip them to relay that information in a convenient way to users.»
Message Header for Indicating Sender Authentication Status (diff)
Updated: Attaching Meaning to Solicitation Class Keywords
Abstract: «This Internet-Draft proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as “org.example.adv”. These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new “No-Solicit:” header which can contain one This draft specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the “example.org” domain could use this mechanism to create a URI which contains detailed information about the “org.example.adv” solicitation class keyword.»
Attaching Meaning to Solicitation Class Keywords (diff)
Updated: IMAP ANNOTATE Extension
Abstract: «The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain “metadata” for messages stored in an IMAP mailbox.»