Email forwarding

Email forwarding

Email forwarding consists of the operation of re-sending an email message delivered to one email address on to another email address. Users and administrators of email systems use the same term when speaking of both server-based and client-based forwarding.

Email forwarding can also redirect mail going to one address and send it to one or several other addresses. "Vice versa", email items going to several different addresses can converge via forwarding to end up in a single address in-box.

Server-based forwarding

The domain name (the part appearing to the right of "@" in an email address) defines the target server [The primary MX record of the relevant domain usually publishes the name of the mail server. Otherwise the domain name must have an IP address.] for that class of addresses. That server can deliver a message to a user's mailbox and/or send it forward. ~/.forward files (see below) provide a typical example of the implementation of server-based forwarding.

Email administrators sometimes use the term "redirection" as a synonym for server-based email-forwarding.

Uses of server-based forwarding

; Role-addresses : "info", "sales", "postmaster", and similar names can appear to the left of "@" in email addresses. An organization may forward messages intended for a given role to the personal address of the person(s) functioning in that role or office.; Vanity-addresses : Most domain name hosting facilities provide mail-facilities to forward mail to another email address such as the user's Internet Service Provider.; Dismissed addresses : When users change their email addresses, an administrator may set up forwarding from an old address to a current one in order to avoid losing messages.

Forwarding versus remailing

Plain message-forwarding changes the envelope recipient(s) and leaves the envelope sender field untouched. The "envelope sender" field does not equate to the "From" header which Email client software usually displays: it represents a field used in the early stages of the SMTP protocol, and subsequently saved as the "Return-Path" header. This field holds the address to which mail-systems must send bounce messages — reporting delivery-failure (or success) — if any.

By contrast, the terms "remailing" or "redistribution" can sometimes mean re-sending the message and also rewriting the "envelope sender" field. Electronic mailing lists furnish a typical example. Authors submit messages to a "reflector" that performs remailing to each list address. That way, bounce messages (which report a failure delivering a message to any list- subscriber) will not reach the author of a message. However, annoying misconfigured "vacation" autoreplies do reach authors.

Typically, plain message-forwarding does alias-expansion, while proper message-forwarding, also named "forwarding" tout-court [In section 3.9.2 "List" of RFC 5321, the term "forwarding" is used ambiguously. It notes that "the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the ["Return-Path" header] "." That wording, new w.r.t. RFC 2821, could be interpreted as the definition of "forwarding", if the same term weren't used at the beginning of the same subsection with the opposite meaning.] serves for mailing-lists. When additional modifications to the message are carried out, so as to rather resemble the action of a MUA submitting a new message, the term "forwarding" becomes deceptive and remailing seems more appropriate.

In the Sender Policy Framework (SPF), the domain-name in the envelope sender remains subject to policy restrictions. Therefore, SPF generally disallows plain message-forwarding. "Intra domain" redirection complies with SPF as long as the relevant servers share a consistent configuration. Mail servers that practise "inter-domain" message-forwarding may break SPF even if they don't implement SPF themselves, i.e. they neither apply SPF checks nor publish SPF records.Consider the following forward path:
"A"-> "B" -> "C"
Domain "B" must not plainly forward a message from domain "A" to domain "C", unless it controls either the policy of "A" or the filtering of "B". Indeed, if "A" publishes an SPF policy that prevents "B" from using "A"'s name, and "C" applies sender's policy-checking, "C" may refuse the message according to RFC 4408. In other words, one cannot formally distinguish plain message-forwarding from illegal domain-name abuse.]
Sender Rewriting Scheme provides for a generic forwarding mechanism compatible with SPF.

Client-based forwarding

Automated client-based forwarding

Client forwarding can take place automatically using a non-interactive client such as a mail retrieval agent. Although the retrieval agent uses a client protocol, this forwarding resembles "server forwarding" in that it keeps the same message-identity. Concerns about the envelope-sender apply.

Manual client-based forwarding

An end-user can "manually" forward a message using an Email client. Forwarding "inline" quotes the message below the main text of the new message, and preserves original attachments. Forwarding "as attachment" prepares a MIME attachment that contains the full original message, including all headers and any attachment. Note that including all the headers discloses much information about the message, such as the servers that transmitted it and any client-tag added on the mailbox.

This kind of forwarding actually constitutes a "remailing" from the points of view of the envelope-sender and of the recipient(s). The message identity also changes.

Historical development of email forwarding

RFC 821, "Simple Mail Transfer Protocol", by Jonathan B. Postel in 1982, provided for a "forward-path" for each recipient, in the form of, for example, @USC-ISIE.ARPA, @USC-ISIF.ARPA: Q-Smith@ISI-VAXA.ARPA — an optional list of hosts and a required destination-mailbox. When the list of hosts existed, it served as a source-route, indicating that each host had to relay the mail to the next host on the list. Otherwise, in the case of insufficient destination-information but where the server knew the correct destination, it could take the responsibility to deliver the message by responding as follows:

S: RCPT TO: R: 251 User not local; will forward to

The concept at that time envisaged the elements of the "forward-path" (source route) moving to the "return-path" (envelope sender) as a message got relayed from one SMTP server to another. Even if the system discouraged the use of source-routing, [See the note in section 6.2.7 "Explicit path specification" of RFC 822] dynamically building the "return-path" implied that the "envelope sender" information could not remain in its original form during forwarding. Thus RFC 821 did not originally allow plain message-forwarding.

The introduction of the MX record [MX record has been introduced with RFC 974. See the historical section in MX record#History of fallback to A.] made source-routing unnecessary. In 1989, RFC 1123 recommended accepting source-routing only for backward-compatibility. At that point, plain message forwarding became the recommended action for alias-expansion. In 2008, RFC 5321 still mentions that "systems "may" remove the return path and rebuild " [it] " as needed", taking into consideration that not doing so might inadvertently disclose sensitive information. [Plain message forwarding may disclose the final destination-address irrespectively of the user's intention. See sections 7.7 "Information Disclosure in Message Forwarding", and 4.4 "Trace Information" in RFC 5321.] Actually, plain message-forwarding can be conveniently used for alias expansion within the same server or a set of coordinated servers.

~/.forward files

sendmail, the reference SMTP implementation in the early 1980s, provided for ~/.forward files, which can store the target email-addresses for given users. One can configure some email-program filters to automatically perform forwarding or replying actions immediately after receiving. Forward files can also contain shell scripts, which have become a source of many security problems. Formerly only trusted users could utilize the command-line switch for setting the envelope sender, -f "arg"; some systems disabled this feature for security reasons. [cite book
last = Hunt
first = Craig
title = TCP/IP Network Administration
publisher = O'Reilly
date = 2002
location =
pages = page 606
isbn = 059600334X
The current (version 8.708 of 2006) [http://www.sendmail.org/doc/sendmail-current/doc/op/op.pdf sendmail documentation] mentions no restrictions in using the -f switch, and uses the verb "set" rather than "override" to describe its action on the envelope sender data.
]

Email predates the formalization of client-server architectures in the 1990s. [The book dates in [ftp://ftp.uu.net/usenet/news.answers/client-server-faq.Z client-server-faq] range from the early 1990s. Although remote procedure calls originated in the 1970s, they did not become widely used until networks became quite common.] Therefore, the distinction between client and server seems necessarily forced. The original distinction contrasted daemons and user-controlled programs which run on the same machine. The sendmail daemon used to run with root privileges so it could impersonate any user whose mail it had to manage. On the other hand, users can access their own individual mail-files and configuration files, including ~/.forward. Client programs may assist in editing the server configuration-files of a given user, thereby causing some confusion as to what role each program plays.

Virtual users

The term "virtual users" refers to email users who never log on a mail-server system and only access their mailboxes using remote clients. A mail-server program may work for both virtual and regular users, or it may require minor modifications to take advantage of the fact that virtual users frequently share the same system "id". The latter circumstance allows the server program to implement some features more easily, as it doesn't have to obey system-access restrictions. The same principles of operations apply. However, virtual users have more difficulty in accessing their configuration files, for good or ill.

Notes

See also

* Chain E-mail
* Electronic mailing list
* E-mail alias
* E-mail client
* Reply All
* E-mail spam

External links

* [http://www.feep.net/sendmail/tutorial/intro/forward.html sendmail and the .forward file]
* [http://directory.google.com/Top/Computers/Internet/E-mail/Forwarding/ Google - E-mail Forwarding]
* [http://video.about.com/email/GmailAliasForwarding-mov.htm Email alias and forwarding in Gmail]


Wikimedia Foundation. 2010.

Игры ⚽ Поможем написать курсовую

Look at other dictionaries:

  • Email box — An email box (also email mailbox, e mailbox) is the equivalent of a letter box for electronic mail. It is the destination where electronic mail messages are delivered. Contents 1 Definitions 2 Access 3 Storage format …   Wikipedia

  • Email mailbox — An Email mailbox is the email equivalent of a Letter box, it is where email messages are delivered. Usage An Email client retrieves messages from one or more mailboxes. The file or directory where the client stores the messages is called the… …   Wikipedia

  • Email loop — An email loop is an infinite loop phenomenon, resulting from mail servers, scripts, or email clients that generate automatic replies or responses. If one such automatic response triggers another automatic response on the other side, an email loop …   Wikipedia

  • forwarding — for·ward·ing || fÉ”rwÉ™(r)dɪŋ / fɔːw n. sending, transferring, dispatching, transmitting, directing onward for·ward || fÉ”rwÉ™(r)d / fɔːw n. player positioned at the front of the offensive line (Sports) v. send, convey; promote; advance; …   English contemporary dictionary

  • Claire Swire email — The Claire Swire email of 2000 was supposedly a very personal email from Claire Swire to Bradley Chait, who worked at Norton Rose, a law firm in London. He forwarded it to six friends, one of whom in turn forwarded it further with the subject… …   Wikipedia

  • Comparison of webmail providers — The following tables and gallery compare general and technical information for a number of webmail providers. Please see the individual products articles for further information. General information Name Owner First public release date Cost (US$) …   Wikipedia

  • E-mail alias — An e mail alias is simply a forwarding e mail address. The term alias expansion is sometimes used to indicate a specific mode of email forwarding, thereby implying a more generic meaning of the term e mail alias as an address that is forwarded in …   Wikipedia

  • Sender Rewriting Scheme — (SRS) is a technique to re mailan email message so that eventual Delivery Status Notificationscan reach the original message sender. In this context, re mailing is an alternative to Email forwarding, which is not allowed bythe Sender Policy… …   Wikipedia

  • MIME — This article is about the email content type system. For the World Wide Web content type system, see Internet media type. For mime as an art form, see Mime artist. For the British engineering society, see Institution of Mechanical Engineers.… …   Wikipedia

  • Message transfer agent — Within Internet message handling services (MHS), a message transfer agent[1] or mail transfer agent[2] (MTA) or mail relay is software that transfers electronic mail messages from one computer to another using a client–server application… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”