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] |