RFC1711
Classifications in E-mail Routing  J. Houttuin October 1994 ASCII   INFORMATIONAL
This paper presents a classification for e-mail routing issues. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC1985
SMTP Service Extension for Remote Message Queue Starting  J. De Winter August 1996 ASCII   PROPOSED STANDARD
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. [STANDARDS-TRACK]
RFC2033
Local Mail Transfer Protocol  J. Myers October 1996 ASCII   INFORMATIONAL
SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC2050
BCP0012
Internet Registry IP Allocation Guidelines  K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel November 1996 ASCII Obsoletes RFC1466  BEST CURRENT PRACTICE
This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC2151
FYI0030
A Primer On Internet and TCP/IP Tools and Utilities  G. Kessler, S. Shepard June 1997 ASCII Obsoletes RFC1739  INFORMATIONAL
This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC2368
The mailto URL scheme  P. Hoffman, L. Masinter, J. Zawinski July 1998 ASCII Updates RFC1738, RFC1808  PROPOSED STANDARD
This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK]
RFC2369
The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields  G. Neufeld, J. Baer July 1998 ASCII   PROPOSED STANDARD
The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. [STANDARDS-TRACK]
RFC2505
BCP0030
Anti-Spam Recommendations for SMTP MTAs G. Lindberg February 1999 ASCII   BEST CURRENT PRACTICE
This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail,) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC2645
ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses  R. Gellens August 1999 ASCII Errata  PROPOSED STANDARD
This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]
RFC2852
Deliver By SMTP Service Extension  D. Newman June 2000 ASCII Updates RFC1894  PROPOSED STANDARD
This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. [STANDARDS TRACK]
STD0060
RFC2920
SMTP Service Extension for Command Pipelining N. Freed September 2000 ASCII Obsoletes RFC2197 STANDARD
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS TRACK]
RFC3043
The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations  M. Mealling January 2001 ASCII   INFORMATIONAL
This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. This memo provides information for the Internet community.
RFC3207
SMTP Service Extension for Secure SMTP over Transport Layer Security  P. Hoffman February 2002 ASCII Obsoletes RFC2487
Errata 
PROPOSED STANDARD
This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS TRACK]
RFC3461
Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)  K. Moore January 2003 ASCII Obsoletes RFC1891, Updated by RFC3798, RFC3885, RFC5337
Errata 
DRAFT STANDARD
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS TRACK]
RFC3463
Enhanced Mail System Status Codes  G. Vaudreuil January 2003 ASCII Obsoletes RFC1893, Updated by RFC3886, RFC4468, RFC4865, RFC4954, RFC5248  DRAFT STANDARD
This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS TRACK]
RFC3609
Tracing Requirements for Generic Tunnels  R. Bonica, K. Kompella, D. Meyer September 2003 ASCII   INFORMATIONAL
This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding. The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers. Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by an IP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.
RFC3848
ESMTP and LMTP Transmission Types Registration  C. Newman July 2004 ASCII   PROPOSED STANDARD
This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message. [STANDARDS TRACK]
RFC3865
A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension  C. Malamud September 2004 ASCII   PROPOSED STANDARD
This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. [STANDARDS TRACK]
RFC3885
SMTP Service Extension for Message Tracking  E. Allman, T. Hansen September 2004 ASCII Updates RFC3461  PROPOSED STANDARD
This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS TRACK]
RFC3887
Message Tracking Query Protocol  T. Hansen September 2004 ASCII Errata  PROPOSED STANDARD
Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. [STANDARDS TRACK]
RFC3888
Message Tracking Model and Requirements  T. Hansen September 2004 ASCII   INFORMATIONAL
Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. This memo provides information for the Internet community.
RFC3974
SMTP Operational Experience in Mixed IPv4/v6 Environments  M. Nakamura, J. Hagino January 2005 ASCII   INFORMATIONAL
This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.
This document does not define any new protocol. This memo provides information for the Internet community.
STD0066
RFC3986
Uniform Resource Identifier (URI): Generic Syntax T. Berners-Lee, R. Fielding, L. Masinter January 2005 ASCII Obsoletes RFC2732, RFC2396, RFC1808, Updates RFC1738 STANDARD
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS TRACK]
RFC4095
Attaching Meaning to Solicitation Class Keywords  C. Malamud May 2005 ASCII   PROPOSED STANDARD
This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, 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 or more solicitation class keywords inserted by the sender.
This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 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. [STANDARDS TRACK]
RFC4130
MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)  D. Moberg, R. Drummond July 2005 ASCII   PROPOSED STANDARD
This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335. [STANDARDS TRACK]
RFC4183
A Suggested Scheme for DNS Resolution of Networks and Gateways  E. Warnicke September 2005 ASCII   INFORMATIONAL
This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet. This memo provides information for the Internet community.
RFC4409
Message Submission for Mail  R. Gellens, J. Klensin April 2006 ASCII Obsoletes RFC2476
Errata 
DRAFT STANDARD
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
Message relay and final delivery are unaffected, and continue to use SMTP over port 25.
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS TRACK]
RFC4501
Domain Name System Uniform Resource Identifiers  S. Josefsson May 2006 ASCII Errata  PROPOSED STANDARD
This document defines Uniform Resource Identifiers for Domain Name System resources. [STANDARDS TRACK]
RFC4516
Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator  M. Smith, Ed., T. Howes June 2006 ASCII Obsoletes RFC2255
Errata 
PROPOSED STANDARD
This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. [STANDARDS TRACK]
RFC4560
Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations  J. Quittek, Ed., K. White, Ed. June 2006 ASCII Obsoletes RFC2925  PROPOSED STANDARD
This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host.
Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. [STANDARDS TRACK]
RFC4865
SMTP Submission Service Extension for Future Message Release  G. White, G. Vaudreuil May 2007 ASCII Updates RFC3463, RFC3464  PROPOSED STANDARD
This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS TRACK]
RFC4954
SMTP Service Extension for Authentication  R. Siemborski, Ed., A. Melnikov, Ed. July 2007 ASCII Obsoletes RFC2554, Updates RFC3463, Updated by RFC5248
Errata 
PROPOSED STANDARD
This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.
This document obsoletes RFC 2554. [STANDARDS TRACK]
RFC4984
Report from the IAB Workshop on Routing and Addressing  D. Meyer, Ed., L. Zhang, Ed., K. Fall, Ed. September 2007 ASCII   INFORMATIONAL
This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.
RFC5065
Autonomous System Confederations for BGP  P. Traina, D. McPherson, J. Scudder August 2007 ASCII Obsoletes RFC3065
Errata 
DRAFT STANDARD
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.
This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.
This document obsoletes RFC 3065. [STANDARDSD TRACK]
RFC5068
BCP0134
Email Submission Operations: Access and Accountability Requirements  C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch November 2007 ASCII   BEST CURRENT PRACTICE
Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.
Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5092
IMAP URL Scheme  A. Melnikov, Ed., C. Newman November 2007 ASCII Obsoletes RFC2192, Updates RFC4467
Errata 
PROPOSED STANDARD
IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.
This document obsoletes RFC 2192. It also updates RFC 4467. [STANDARDS TRACK]
RFC5248
BCP0138
A Registry for SMTP Enhanced Mail System Status Codes  T. Hansen, J. Klensin June 2008 ASCII Updates RFC3463, RFC4468, RFC4954  BEST CURRENT PRACTICE
The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes. While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5321
Simple Mail Transfer Protocol  J. Klensin October 2008 ASCII Obsoletes RFC5321, Updates RFC1123  DRAFT STANDARD
This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS TRACK]
RFC5322
Internet Message Format  P. Resnick, Ed. October 2008 ASCII Obsoletes RFC5322, Updates RFC4021  DRAFT STANDARD
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS TRACK]
RFC5336
SMTP Extension for Internationalized Email Addresses  J. Yao, Ed., W. Mao, Ed. September 2008 ASCII Updates RFC5321, RFC5322, RFC4952
Errata 
EXPERIMENTAL
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 5321 and RFC 5322, and has some material updating RFC 4952This memo defines an Experimental Protocol for the Internet community.
RFC5343
Simple Network Management Protocol (SNMP) Context EngineID Discovery  J. Schoenwaelder September 2008 ASCII Updates RFC3411  PROPOSED STANDARD
The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.
This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.
This document updates RFC 3411. [STANDARDS TRACK]
RFC5350
IANA Considerations for the IPv4 and IPv6 Router Alert Options  J. Manner, A. McDonald September 2008 ASCII Updates RFC2113, RFC3175  PROPOSED STANDARD
This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS TRACK]