Internet
Click on the red underlined text to get to the source
... SMTP is widely deployed and high-quality implementations have proven
to be very robust. However, the Internet community now considers
some services to be important that were not anticipated when the
...
... MTAs
often do not accurately match common, and conforming, practices with
Internet mail. Hence, the reader should be cautious about inferring
the strong relationships and responsibilities that might be implied
if these terms were used elsewhere.
...
... For the purposes of this specification, a host is a computer system
attached to the Internet (or, in some cases, to a private TCP/IP
network ...
... electronic mail. An "originating" system (sometimes called an SMTP
originator) introduces mail into the Internet or, more generally,
into a transport service environment. A "delivery ...
... The metalinguistic notation used in this document corresponds to the
"Augmented BNF" used in other Internet mail system documents. The
reader who is not familiar with that syntax should consult the ABNF
specification [8 ...
... clients MUST NOT
assume that any SMTP server on the Internet can be used as their mail
processing (relaying) site. If a RCPT command appears without a
previous MAIL command ...
... mailboxes as "user names". However, since
current Internet practice often results in a single host handling
mail for multiple domains ...
... for a file containing a mailing list, but again there are a variety
of file naming conventions in the Internet. Similarly, historical
variations in what is returned by these commands are such that the
response SHOULD be interpreted very carefully, if at all, and SHOULD
...
... mailing lists as a means of
eliminating duplicates. The propagation of aliasing systems with
mail on the Internet, for hosts (typically with MX and CNAME DNS
records ...
... 27] makes the use of explicit source routes in the
Internet mail system unnecessary. Many historical problems with
their interpretation have made their use undesirable. SMTP clients ...
...
While the relay function discussed above operates within the Internet
SMTP transport service ...
...
Other mail systems gatewayed to the Internet often use a subset of
RFC 822std11(-> 2822prop) headers ...
... syntax, but some of these mail systems do not have an equivalent to
the SMTP envelope. Therefore, when a message leaves the Internet
environment, it may be necessary to fold the SMTP envelope
information into the message header ...
...
When forwarding a message into or out of the Internet environment, a
gateway MUST prepend a Received: line, but it MUST NOT alter in any
...
... headers generated by gateways MUST
conform to applicable Internet standards (including this one and RFC
822std11(-> 2822prop)). Gateways ...
... gateway MUST ensure that all header fields of a message that it
forwards into the Internet mail environment meet the requirements for
Internet mail ...
... Internet mail environment meet the requirements for
Internet mail. In particular, all addresses in "From:", "To:",
"Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC
...
... MUST be effective and useful for sending replies. The translation
algorithm used to convert mail from the Internet protocols to another
environment's protocol SHOULD ensure that error messages from the
...
...
Similarly, when forwarding a message from another environment into
the Internet, the gateway SHOULD set the envelope return path in
accordance with an error message ...
... by dots and enclosed by brackets such as [123.255.37.2], which
indicates an (IPv4) Internet Address in sequence-of-octets form. For
IPv6 and other forms of addressing ...
...
An Internet mail program MUST NOT change a Received: line that was
previously added to the message header. SMTP servers ...
...
As the Internet grows, comparability of Received fields is important
for detecting problems, especially slow relays. SMTP servers that
...
... destination for error messages is not
applicable on the Internet. The reverse path address (as copied into
the Return-path ...
... unless it is known that the "elsewhere" transport also uses
Internet domain addresses and maintains the envelope sender ...
... Atom ; Additional standard names for links are registered with the Internet Assigned Numbers Authority (IANA). "Via" is primarily of value with non-Internet transports ...
... links are registered with the Internet Assigned Numbers Authority (IANA). "Via" is primarily of value with non-Internet transports. SMTP servers SHOULD NOT use unregistered ...
... Atom ; Additional standard names for protocols are registered with the Internet Assigned Numbers Authority (IANA). SMTP servers SHOULD NOT use unregistered ...
... SMTP systems are expected to make every reasonable effort to accept
mail directed to Postmaster from any other system on the Internet.
In extreme cases --such as to contain a denial of service attack or
...
... Every implementation MUST be able to receive objects of at least
these sizes. Objects larger than these sizes SHOULD be avoided when
possible. However, some Internet mail constructs such as encoded
X.400 addresses ...
... message headers as well as the message body) MUST BE at least 64K
octets. Since the introduction of Internet standards for
multimedia mail [12], message lengths on the Internet ...
... Internet standards for
multimedia mail [12], message lengths on the Internet have grown
dramatically, and message size restrictions should be avoided if
...
... unavailable destination host. If all of these messages were retried
in every retry cycle, there would be excessive Internet overhead and
the sending system would be blocked for a long period. Note that an
...
...
Unfortunately, variations, creative interpretations, and outright
violations of Internet mail protocols do occur; some would suggest
that they occur quite frequently. The debate as to whether a well-
behaved SMTP ...
... SMTP servers as relay systems for these client hosts
(which are often only intermittently connected to the Internet).
Historically, many of those client machines lacked some of the
...
... expert is somewhat more difficult, but not sufficiently so as to be a
deterrent to someone who is determined and knowledgeable.
Consequently, as knowledge of Internet mail increases, so does the
knowledge that SMTP mail inherently cannot be authenticated ...
... LAN
whose hosts are not directly on the public Internet, trace
("Received") fields produced in conformance with this specification
...
... accept mail for any operational or technical reason that makes sense
to the site providing the server. However, cooperation among sites
and installations makes the Internet possible. If sites take
excessive advantage of the right to reject traffic, the ubiquity of
...
... traffic, the ubiquity of
email availability (one of the strengths of the Internet) will be
threatened; considerable care should be taken and balance maintained
if a site decides to be selective about the traffic ...
... ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. ...
... Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123std3 ...
... Crispin, M., "Internet Message Access Protocol - Version 4", RFC 2060(-> 3501prop), December 1996. ...
... Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822std11(-> 2822prop), August 1982. ...
... Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045draft ...
... Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045draft, December 1996. ...
... Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047draft ...
... Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793std7 ...
... Resnick, P., Ed., "Internet Message Format", RFC 2822prop, April 2001. ...
... about many technical issues and the role of a revised standard for
Internet mail transport, and many contributors helped form the
wording in this specification. The hundreds of participants in the
...
... MTA-UA
protocol is a private matter, not covered by any Internet Standard,
there are problems with this approach. For example, there have been
repeated problems with proper handling of "bcc" copies and
...
... header "to" and "cc"
fields have repeatedly caused mail loops and other behavior adverse
to the proper functioning of the Internet mail environment. These
problems have been especially common when the message originates from
an Internet ...
... Internet mail environment. These
problems have been especially common when the message originates from
an Internet mailing list and is distributed into the foreign
environment using envelope information. When these messages are then
...
... environment using envelope information. When these messages are then
processed by a header-only remailer, loops back to the Internet
environment (and the mailing list) are almost inevitable.
...
...
In general, gateways between the Internet and other mail systems
SHOULD attempt to preserve any layering semantics across the
...
... important ways. Systems translating between environments that do not
support both envelopes and headers and Internet mail must be written
with the understanding that some information loss is almost
inevitable.
...
... A few features of RFC 821std10(-> 2821prop) have proven to be problematic and SHOULD
NOT be used in Internet mail.
...
...
RFC 821std10(-> 2821prop) provided for specifying an Internet address as a decimal
integer host ...
... trace fields), four-digit years MUST BE used. Two-digit
years are deprecated; three-digit years were never permitted in the
Internet mail system.
...
...
Copyright (C) The Internet Society (2001). All Rights Reserved.
...
... document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
...
... the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
...
... Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
...
... developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
...
...
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
...
... This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
...
... "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ...
...
Funding for the RFC Editor function is currently provided by the
Internet Society.
...