|
|
5.2.6 Mail Relay: RFC-821 Section 3.6
Connected: An Internet Encyclopedia
5.2.6 Mail Relay: RFC-821 Section 3.6
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1123
Up:
5. ELECTRONIC MAIL -- SMTP and RFC-822
Up:
5.2 PROTOCOL WALK-THROUGH
Prev: 5.2.5 HELO Command: RFC-821 Section 3.5
Next: 5.2.7 RCPT Command: RFC-821 Section 4.1.1
5.2.6 Mail Relay: RFC-821 Section 3.6
5.2.6 Mail Relay: RFC-821 Section 3.6
We distinguish three types of mail (store-and-) forwarding:
- A simple forwarder or "mail exchanger" forwards a message
using private knowledge about the recipient; see section
3.2 of RFC-821.
- An SMTP mail "relay" forwards a message within an SMTP
mail environment as the result of an explicit source route
(as defined in section 3.6 of RFC-821). The SMTP relay
function uses the "@...:" form of source route from RFC-
822 (see Section 5.2.19 below).
- A mail "gateway" passes a message between different
environments. The rules for mail gateways are discussed
below in Section 5.3.7.
An Internet host that is forwarding a message but is not a
gateway to a different mail environment (i.e., it falls under
(1) or (2)) SHOULD NOT alter any existing header fields,
although the host will add an appropriate Received: line as
required in Section 5.2.8.
A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
explicit source route using the "@...:" address form. Thus,
the relay function defined in section 3.6 of RFC-821 should
not be used.
- DISCUSSION:
The intent is to discourage all source routing and to
abolish explicit source routing for mail delivery within
the Internet environment. Source-routing is unnecessary;
the simple target address "user@domain" should always
suffice. This is the result of an explicit architectural
decision to use universal naming rather than source
routing for mail. Thus, SMTP provides end-to-end
connectivity, and the DNS provides globally-unique,
location-independent names. MX records handle the major
case where source routing might otherwise be needed.
A receiver-SMTP MUST accept the explicit source route syntax in
the envelope, but it MAY implement the relay function as
defined in section 3.6 of RFC-821. If it does not implement
the relay function, it SHOULD attempt to deliver the message
directly to the host to the right of the right-most "@" sign.
- DISCUSSION:
For example, suppose a host that does not implement the
relay function receives a message with the SMTP command:
"RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
GAMMA represent domain names. Rather than immediately
refusing the message with a 550 error reply as suggested
on page 20 of RFC-821, the host should try to forward the
message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
Since this host does not support relaying, it is not
required to update the reverse path.
Some have suggested that source routing may be needed
occasionally for manually routing mail around failures;
however, the reality and importance of this need is
controversial. The use of explicit SMTP mail relaying for
this purpose is discouraged, and in fact it may not be
successful, as many host systems do not support it. Some
have used the "%-hack" (see Section 5.2.16) for this
purpose.
Next: 5.2.7 RCPT Command: RFC-821 Section 4.1.1
Connected: An Internet Encyclopedia
5.2.6 Mail Relay: RFC-821 Section 3.6
|
|
|
 |

|
 |
|
Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
| |
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
| |
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
| |
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
| |
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!
|
|
Service Details
|
|
 |
|