Server-based forwarding
The domain name (the part appearing to the right of @ in an email address) defines the target server(s) [2] for the corresponding class of addresses. A domain may also define backup servers; they have no mailboxes and forward messages without changing any part of their envelopes. [3] By contrast, primary servers can deliver a message to a user's mailbox and/or forward it by changing some envelope addresses. ~/.forward files (see below) provide a typical example of server-based forwarding to different recipients.
Email administrators sometimes use the term redirection as a synonym for server-based email-forwarding to different recipients. Protocol engineers sometimes use the term Mediator to refer to a forwarding server. [4]
Because of spam, it is becoming increasingly difficult to reliably forward mail across different domains, and some recommend avoiding it if at all possible. [5]
Uses of server-based forwarding to different recipients
- Role-addresses
- info, sales, postmaster, and similar names [6] can appear to the left of @ in email addresses. An organization may forward messages intended for a given role to the address of the person(s) currently functioning in that role or office.
- Pseudonym-addresses
- Most domain name hosting facilities provide facilities to forward mail to another email address such as a mailbox at the user's Internet Service Provider; there are also separate providers of mail forwarding services. This allows users to have an email address that does not change if they change mailbox provider.
- Multiple, or discontinued addresses
- When users change their email address, or have several addresses, the user or an administrator may set up forwarding from these addresses, if still valid, to a single 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 [1] serves for mailing-lists. When additional modifications to the message are carried out, so as to rather resemble the action of a Mail User Agent 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. In case of forwarding, the email is being sent from the forwarding server, which is not authorized to send emails for the original sender's domain. So the SPF will fail. [7] Intra domain redirection complies with SPF as long as the relevant servers share a consistent configuration. Mail servers that practice inter-domain message-forwarding may break SPF even if they do not implement SPF themselves, i.e. they neither apply SPF checks nor publish SPF records. [8] Sender Rewriting Scheme provides for a generic forwarding mechanism compatible with SPF.
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:RCPTTO:<Postel@USC-ISI.ARPA>R:251Usernotlocal;willforwardto<Postel@USC-ISIF.ARPA>
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, [9] 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 [10] made source-routing unnecessary. In 1989, RFC 1123 recommended accepting source-routing only for backward-compatibility. At that point, plain message forwarding [8] 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. [11] Actually, plain message-forwarding can be conveniently used for alias expansion within the same server or a set of coordinated servers.
~/.forward files
The reference SMTP implementation in the early 1980s was sendmail, which provided for ~/.forward files, which can store the target email-addresses for given users. This kind of server-based forwarding is sometimes called dot-forwarding. [12] 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. [13]
Email predates the formalization of client–server architectures in the 1990s. [14] 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 does not 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.
Electronic mail is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.
Within the Internet email system, a message transfer agent (MTA), mail transfer agent, or mail relay is software that transfers electronic mail messages from one computer to another using the Simple Mail Transfer Protocol. In some contexts, the alternative names mail server, mail exchanger, or MX host are used to describe an MTA.
The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.
An open mail relay is a Simple Mail Transfer Protocol (SMTP) server configured in such a way that it allows anyone on the Internet to send e-mail through it, not just mail destined to or originating from known users. This used to be the default configuration in many mail servers; indeed, it was the way the Internet was initially set up, but open mail relays have become unpopular because of their exploitation by spammers and worms. Many relays were closed, or were placed on blacklists by other servers.
An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.
An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to just the addr-spec in Section 3.4 of RFC 5322. The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.
Various anti-spam techniques are used to prevent email spam.
Sender Policy Framework (SPF) is an email authentication method which ensures the sending mail server is authorized to originate mail from the email sender's domain. This authentication only applies to the email sender listed in the "envelope from" field during the initial SMTP connection. If the email is bounced, a message is sent to this address, and for downstream transmission it typically appears in the "Return-Path" header. To authenticate the email address which is actually visible to recipients on the "From:" line, other technologies such as DMARC must be used. Forgery of this address is known as email spoofing, and is often used in phishing and email spam.
Greylisting is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again after a delay, and if sufficient time has elapsed, the email will be accepted.
A bounce message or just "bounce" is an automated message from an email system, informing the sender of a previous message that the message has not been delivered. The original message is said to have "bounced".
Sender ID is an historic anti-spoofing proposal from the former MARID IETF working group that tried to join Sender Policy Framework (SPF) and Caller ID. Sender ID is defined primarily in Experimental RFC 4406, but there are additional parts in RFC 4405, RFC 4407 and RFC 4408.
Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.
The Sender Rewriting Scheme (SRS) is a scheme for bypassing the Sender Policy Framework's (SPF) methods of preventing forged sender addresses. Forging a sender address is also known as email spoofing.
DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email, a technique often used in phishing and email spam.
Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing email, email scams and other cyber threat activities.
An email alias is simply a forwarding email 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 email alias as an address that is forwarded in a simplistic fashion.
A mailbox is the destination to which electronic mail messages are delivered. It is the equivalent of a letter box in the postal system.
Backscatter is incorrectly automated bounce messages sent by mail servers, typically as a side effect of incoming spam.
A bounce address is an email address to which bounce messages are delivered. There are many variants of the name, none of them used universally, including return path, reverse path, envelope from, envelope sender, MAIL FROM, 5321-FROM, return address, From_, Errors-to, etc. It is not uncommon for a single document to use several of these names.
SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol (SMTP) whereby a client may log in using any authentication mechanism supported by the server. It is mainly used by submission servers, where authentication is mandatory.
