Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Email forwarding.
Nothing was collected or created yet.
Email forwarding
View on Wikipediafrom Wikipedia
Email forwarding generically refers to the operation of re-sending a previously delivered email to an email address to one or more different email addresses.
The term forwarding, used for mail since long before electronic communications, has no specific technical meaning,[1] but it implies that the email has been moved "forward" to a new destination.
Email forwarding can also redirect mail going to a certain address and send it to one or more other addresses. Vice versa, email items going to several different addresses can converge via forwarding to end up in a single address in-box.[clarification needed]
Email users and administrators of email systems use the same term when speaking of both server-based and client-based forwarding.
Server-based forwarding
[edit]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
[edit]- 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
[edit]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.
Client-based forwarding
[edit]Automated client-based forwarding
[edit]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.[8]
Manual client-based forwarding
[edit]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 usually preserves original attachments as well as a choice of selected headers (e.g. the original From and Reply-To.) The recipient of a message forwarded this way may still be able to reply to the original message; the ability to do so depends on the presence of original headers and may imply manually copying and pasting the relevant destination addresses.
Forwarding as attachment prepares a MIME attachment (of type message/rfc822) 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. The recipient of a message forwarded this way may be able to open the attached message and reply to it seamlessly.
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
[edit]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:<Postel@USC-ISI.ARPA>
R: 251 User not local; will forward to <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
[edit]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
[edit]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.
See also
[edit]Notes
[edit]- ^ a b 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. As a contributor to RFC 5321 agreed, Tony Finch (2008-11-03). "English terms for forwarded addresses". IETF. Archived from the original on 2008-12-11. Retrieved 2008-11-07.
[forwarding is] a fuzzy (non-technical) term in SMTP
- ^ 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.
- ^ The envelope of a message is the data transmitted in an SMTP transaction before transmitting the content of the message. The envelope is lost when the message is delivered, although some of its fields may be saved by the receiving server in the message's headers. In particular, the envelope holds the Return-Path (a.k.a. bounce address, MAIL FROM argument, mailfrom, or mfrom) and one or more recipients (including Bcc's).
- ^ Dave Crocker (July 2009). "Mediators". Internet Mail Architecture. IETF. sec. 5. doi:10.17487/RFC5598. RFC 5598. Retrieved 19 March 2013.
A Mediator forwards a message through a re-posting process. The Mediator shares some functionality with basic MTA relaying, but has greater flexibility in both addressing and content than is available to MTAs.
- ^ John Levine (2008-10-15). "Users Don't Like Forwarded Spam". CircleID. Retrieved 2008-11-07.
- ^ RFC 2142, "Mailbox Names for Common Services, Roles and Functions", 1997, mentions also marketing, support, abuse, security, webmaster, and more.
- ^ "How does email forwarding affect authentication result?". ProDMARC. 6 January 2023. Retrieved 16 March 2023.
- ^ a b c
Consider the following forward path:
- A → B → C
- ^ See the note in section 6.2.7 Explicit path specification of RFC 822
- ^ MX record has been introduced with RFC 974. See the historical section in MX record#History of fallback to A.
- ^ 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.
- ^ Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (September 2016). "Alias". Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows. IETF. sec. 3.2.1. doi:10.17487/RFC7960. RFC 7960. Retrieved 14 March 2017.
- ^
Hunt, Craig (2002). TCP/IP Network Administration. O'Reilly. p. 606. ISBN 0-596-00334-X.
The current[update] (version 8.708 of 2006) sendmail documentation mentions no restrictions in using the
-fswitch, and uses the verb set rather than override to describe its action on the envelope sender data. - ^ The book dates in client-server-faq[dead link] range from the early 1990s. Although remote procedure calls originated in the 1970s, they did not become widely used until networks became quite common.
Email forwarding
View on Grokipediafrom Grokipedia
Email forwarding is the process of automatically redirecting incoming email messages from an original recipient's address to one or more alternative addresses, enabling efficient management of communications without the need to monitor multiple inboxes.[1][2] This functionality operates at the server or client level, where server-based forwarding handles redirection transparently via the email server—often using MX records and preserving the original message path—while client-based forwarding involves the user's email application resending the message, which may alter headers and attachments.[2][3]
The origins of email forwarding trace back to the early development of electronic mail standards in the 1970s. Initial email specifications, such as RFC 561 (1973), introduced basic header fields like "From," with "To" fields and forwarding mechanisms formalized in RFC 733 (1977) within the ARPANET framework.[4] Subsequent protocols such as RFC 821 (1982) detailed mechanisms for forwarding mail during SMTP transmission, including options for verifying mailboxes and expanding lists.[5][6] Over time, forwarding became a core feature in commercial email systems, with modern implementations like those in Microsoft 365 and Gmail allowing administrators or users to configure rules for internal or external redirection, often with options to retain copies in the original mailbox.[1][7][8][9]
Key benefits of email forwarding include consolidating messages from various domains or aliases into a single account, which simplifies inbox organization and reduces the risk of missing important communications, such as redirecting emails from former employees to current staff.[2] It also supports cost-effective setups for businesses by eliminating the need for multiple full email hosting accounts, while facilitating seamless transitions during domain changes or mergers.[2] However, forwarding introduces notable risks, particularly in security and deliverability: it can break email authentication protocols like SPF and DKIM, leading to messages being flagged as spam or rejected, and external forwarding may bypass organizational spam filters, exposing sensitive data to phishing or unauthorized exfiltration.[10][11] To mitigate these, protocols like ARC (RFC 8617) preserve authentication chains during forwarding, and administrators often implement policies to restrict or monitor external rules.[11][12]
Overview
Definition and purpose
Email forwarding is the automatic redirection of an incoming email message from one email address to one or more other recipient addresses, while preserving the original sender, subject, and body content of the message.[13] This process typically occurs without altering the core elements of the message, ensuring that recipients can view it as originally composed.[14] The primary purpose of email forwarding is to allow users to receive messages at a preferred or primary email address, thereby simplifying the management of multiple accounts or enabling seamless distribution to groups. For example, individuals often use it to consolidate incoming emails from various personal or professional addresses into a single inbox for easier oversight, while organizations apply it to route shared notifications or alerts to team members automatically.[7][1] Key benefits of email forwarding include enhanced convenience for multi-device access, as users can retrieve messages from a centralized location without repeatedly logging into separate accounts, and reduced administrative overhead from manual checks across inboxes. This functionality supports greater productivity by streamlining communication flows in both personal and collaborative settings.[15][16]Basic mechanisms
Server-based email forwarding operates through a standardized process on mail servers, where an incoming message is received, evaluated against configured rules, and relayed to designated recipients. Client-based forwarding, in contrast, occurs within email applications and may involve resending the message, potentially altering headers; further details are covered in dedicated sections. When an email arrives at a recipient's mail server, the server accepts it via the Simple Mail Transfer Protocol (SMTP), using commands such as MAIL FROM to specify the sender, RCPT TO for the recipient, and DATA to transmit the message content.[17] The server then inspects the recipient address against forwarding configurations; if a rule applies, the original message is resent via SMTP to one or more target addresses, typically determined by DNS MX records for routing to the appropriate destination server.[17] This relay preserves the message content while adding trace headers, ensuring seamless redirection without altering the core email.[17] The process relies on key email protocols that handle transmission and access. SMTP serves as the primary protocol for both initial delivery and forwarding, enabling servers to push messages across networks reliably.[17] In contrast, Post Office Protocol version 3 (POP3) and Internet Message Access Protocol (IMAP) facilitate client-side retrieval of emails stored on the server, allowing users to download or synchronize messages from their local devices.[18][19] For server-based forwarding, the process occurs before local storage for POP3/IMAP access, thus requiring no recipient intervention or client action to initiate the redirect.[17] To prevent infinite loops during forwarding—where a message could cycle endlessly between servers—systems employ safeguards based on message traceability. Mail servers monitor the number of "Received" headers added at each hop, rejecting messages exceeding a threshold (typically 100) to halt potential loops.[17] These mechanisms ensure robust operation without recursive errors.[17]Server-based forwarding
Delivery mechanisms
In server-based email forwarding, mail transfer agents (MTAs) such as Sendmail and Postfix play a central role in processing incoming messages and applying redirection rules during the delivery phase.[20] These MTAs receive emails via the Simple Mail Transfer Protocol (SMTP) and parse the recipient addresses specified in the envelope to determine if forwarding rules apply. For instance, Postfix's queue manager and delivery agents examine the recipient domain and local part to initiate lookups, while Sendmail's rule set processing evaluates addresses against configuration rules before routing.[21][22] This server-side handling ensures efficient redirection without altering the original message content, typically occurring after SMTP acceptance but before final delivery to a mailbox or remote host.[23] Rule-based redirection in MTAs relies on configurable mapping mechanisms, such as alias files or database lookups, to translate original recipient addresses to one or more forward destinations. In Sendmail, the /etc/aliases file serves as a key component, where entries like "alias: [email protected]" map the alias to the target address, processed by the MTA during the address canonification phase.[22] Postfix employs similar functionality through virtual_alias_maps, configured in its main.cf file (e.g., virtual_alias_maps = hash:/etc/postfix/virtual), which uses hashed database files or other backends like LDAP to perform lookups on full email addresses.[21] These mappings support flexible redirection, including domain-wide or user-specific rules, and are applied transparently to incoming SMTP sessions. Handling of multiple recipients is built-in; for example, a single alias can expand to several addresses (e.g., "team: [email protected], [email protected]"), causing the MTA to generate parallel deliveries while preserving the original message integrity.[24][25] A critical distinction in forwarding involves the separation of the SMTP envelope from the message headers, ensuring traceability and compliance with protocol standards. The envelope recipient, defined by the RCPT TO command in SMTP, is modified by the MTA to reflect the forwarded address, directing delivery to the new destination without impacting error reporting or routing.[23] In contrast, headers such as To:, Cc:, and From: remain unchanged, as they form part of the visible message content and are not used for transport decisions.[26] This approach, often termed "alias expansion," replaces only the envelope recipient (RCPT TO) while leaving header fields intact, preventing loops and maintaining the original sender-recipient context for the end user.[25] Servers like Postfix implement this by rewriting the envelope during the cleanup and queue stages, adding a Received header for the forwarding event but not altering the core message body or headers.[24]Common applications
Server-based email forwarding is commonly employed by individuals to consolidate messages across multiple accounts, particularly during transitions such as changing jobs, moving to a new email provider, or updating domain registrations. For instance, users can set up temporary forwards from an old address to a new one, ensuring continuity without losing important communications; this is facilitated through administrative tools in platforms like Microsoft 365, where emails are automatically redirected to an external or internal recipient while optionally retaining copies in the original mailbox.[1] For example, users of Gmail can configure server-side forwarding to external addresses such as iCloud email, allowing them to consolidate messages and receive push notifications in clients like Apple Mail; this involves adding the forwarding address in Gmail settings and verifying it via the target email service.[7][27] Similarly, in educational settings, students and faculty often forward university emails to personal accounts to avoid managing separate inboxes, for example, some educational institutions allow internal forwarding or limited external redirects, though policies often restrict new external forwarding for security reasons, as seen in changes at institutions like Columbia University since 2019.[28] In organizational contexts, server-based forwarding supports departmental distribution lists, where incoming messages to a shared alias are automatically routed to multiple team members, enhancing collaboration without requiring individual addressing. Businesses utilize this for scenarios like routing inquiries to relevant departments; for example, LuxSci's email alias distribution lists enable forwarding to up to 25 external recipients plus account users, managed via bulk tools for efficient group handling.[29] Catch-all forwards are particularly valuable for support operations, capturing emails sent to any undesignated address within a domain (e.g., random typos like "[email protected]") and redirecting them to a central inbox, a feature implemented in hosting environments to streamline customer service without dedicated mailboxes for every variant.[30] Internet service providers (ISPs) and web hosting services provide server-side forwarding as a core feature for users without custom domains, allowing simple setup through control panels like cPanel to route emails from one address to another. These services often impose limits on the number of recipients to mitigate spam risks; for example, Google Workspace caps the total number of recipient addresses across all address maps at 5,000 and enforces per-user daily limits of 2,000 messages or 10,000 total recipients, while Microsoft Exchange Online applies reduced message size limits (such as 25 MB) for distribution groups exceeding 5,000 recipients to maintain performance.[31][32][33] Hosting providers such as InMotion Hosting enable unlimited forwarders per domain but monitor for excessive usage, typically allowing forwards to a reasonable number of destinations without specifying hard per-forward recipient caps in standard plans.[34]Distinctions from remailing
Server-based email forwarding differs fundamentally from remailing in how it handles message headers and sender identification. In forwarding, the original email's headers, particularly the "From" field containing the sender's address, are preserved as per the Internet Message Format standards, ensuring the recipient can identify the true originator without alteration. This maintains the integrity of the message's provenance, often adding "Resent-" headers (such as Resent-From and Resent-Date) to indicate the forwarding action while leaving the core sender details intact. In contrast, remailing—typically implemented via anonymous remailers—rewrites the sender information by stripping identifying headers like the return address and replacing them with a pseudonym, anonymous code, or the remailer's own address, effectively concealing the original source.[35] These distinctions arise from their respective purposes and use cases. Forwarding supports transparent communication chains, as seen in mailing lists where preserving the original sender's address allows subscribers to reply directly to the author and enables administrators to track message flows for moderation. This transparency is essential for collaborative environments like discussion groups, where accountability and direct interaction are prioritized. Remailing, however, is designed for anonymity, commonly employed in scenarios such as whistleblower communications or privacy-sensitive submissions, where revealing the sender could lead to risks; for instance, early anonymous remailers like those developed in the 1990s facilitated protected exchanges without exposing user identities.[36] Technically, forwarding's header preservation impacts reply functionality and security processes positively for traceability but can complicate modern authentication protocols like SPF, as the forwarding server's IP may trigger checks against the original domain. Replies are routed to the preserved original sender, supporting seamless conversations. Remailing disrupts this by breaking traceability, which hinders spam filtering (as origin cannot be verified) but aligns with its anonymity goals; however, it may route replies through the remailer, adding latency and potential points of failure. This trade-off highlights forwarding's role in reliable, auditable delivery versus remailing's focus on obfuscation.[37]Client-based forwarding
Manual processes
Manual forwarding in email clients involves users directly initiating the process to resend a received message to additional recipients, typically for sharing information on an ad-hoc basis. This method relies on the user's interaction with the client interface, such as Microsoft Outlook or Mozilla Thunderbird, where the original email is selected and processed into a new outgoing message without relying on server-side automation. Unlike automated rules, manual forwarding allows users to review, edit, and customize the content before transmission, ensuring control over the shared information. The process generally begins with opening the email client and locating the desired message in the inbox or other folders. Users select the message by clicking on it, then access the forwarding option through the interface—often via a "Forward" button in the toolbar, a right-click context menu, or a keyboard shortcut like Ctrl+F in Outlook. In Outlook, for instance, this action opens a new compose window with the original message embedded, prompting the user to enter recipient email addresses in the "To" or "Cc" fields and add any personal notes in the body. Similarly, in Thunderbird, selecting "Forward" from the message menu or toolbar inserts the original content into a new message composition window, where recipients are specified and the message is sent after review. This step-by-step approach ensures the forwarded email is treated as a distinct transmission, generating a new message ID and envelope in compliance with email standards like SMTP. Variations in manual forwarding include inline forwarding, where the original message body is inserted directly into the new email's body for seamless reading, and attachment forwarding, which embeds the original as a file attachment to preserve its exact format, including any HTML elements or attachments. In Outlook, users can choose between these modes via options like "Forward" for inline or "Forward as Attachment" for the latter, which helps maintain fidelity for complex messages but may complicate viewing for recipients. Thunderbird defaults to inline forwarding but offers an attachment option through preferences or add-ons, ensuring the forwarded content retains original headers like "From" and "Date" within the attachment. These methods create a new email envelope, which can alter or append headers—such as adding an "In-Reply-To" field—potentially affecting traceability in email threads, as the forward is not a direct relay but a new composition. Common scenarios for manual forwarding include one-off sharing of receipts, event invitations, or system alerts, where users often add commentary or context to the original message before resending to colleagues or contacts. For example, an employee might forward a vendor invoice received via email, appending notes on approval status, to facilitate quick internal review without setting up permanent rules. This flexibility makes manual processes ideal for sporadic needs, though it requires user vigilance to avoid errors like incorrect recipient selection.Automated configurations
Automated configurations in email client software enable users to establish persistent rules that automatically forward incoming messages based on predefined criteria, such as the sender's address, subject line keywords, or recipient details.[38][39] In applications like Apple Mail, users create these rules by accessing the Mail preferences, selecting the Rules tab, and defining conditions (e.g., "From contains [email protected]") paired with the "Forward Message" action to a specified email address.[38] Similarly, in Microsoft Outlook, client-side rules for forwarding are set up through the Rules Wizard, where conditions like sender or subject are matched to actions that forward the email, but these execute only when the Outlook application is running.[39] These setups differ from manual forwarding processes by applying repeatedly to future matching emails without user intervention each time.[38] When using protocols like IMAP or POP3 in client software, synchronization across multiple devices can lead to issues such as duplicate forwards if the same rule triggers on each active client before the original message is marked as processed on the server.[40] For instance, in IMAP configurations, slow synchronization or concurrent access from devices like a desktop client and mobile app may cause the rule to evaluate and forward the email multiple times, resulting in redundant copies at the destination unless unique identifiers or server-side flags are properly managed.[40] POP3 exacerbates this by downloading messages locally without server synchronization, potentially leading to independent rule executions on each device that retrieves the email.[40] A key limitation of these client-side automated configurations is their dependence on the email client being actively running and connected to the internet, as rules do not persist or execute on the server when the application is closed or offline.[41] This contrasts with server-based forwarding, where rules operate continuously regardless of client status, potentially causing missed forwards if the user's device is powered off or disconnected.[41] To mitigate synchronization problems, users should configure rules on a single primary client or use server-side alternatives where available to ensure consistent behavior across devices.[40]Historical development
Origins in early email systems
Email forwarding emerged in the early 1970s within the ARPANET, the precursor to the modern Internet, where initial implementations relied on basic commands for message redirection. In 1972, the MAIL command was specified to enable the distribution of messages to multiple recipients across the network, marking an early form of group redirection that laid the groundwork for forwarding capabilities.[42] In 1971, Ray Tomlinson developed the SNDMSG program for TENEX systems, enabling both local and network messaging over ARPANET. Forwarding capabilities emerged in subsequent tools, such as the HG system (1974-1975) and John Vittal's MSG program at USC-ISI, which introduced comprehensive forwarding features, including the ability to select, reply to, and redirect messages while preserving context, influencing subsequent ARPANET tools until the mid-1980s.[43] To address routing issues in forwarded messages, RFC 680 standardized the 'message-id' field in April 1975, helping detect loops during inter-site redirections.[44] In parallel, mainframe-based systems like IBM's PROFS (Professional Office System), deployed on VM/CMS starting in the late 1970s, supported admin-controlled redirects through distribution lists and aliasing, allowing system administrators to route messages to groups or individuals without user-level automation.[45] These features focused on intra-organizational efficiency, with forwarding limited to privileged operators to maintain security in controlled environments.[46] The 1980s brought standardization through RFC 822, published in 1982 by David H. Crocker, which defined key address fields essential for forwarding, including To, Cc, Bcc, and the "Resent-" prefixed headers (e.g., Resent-To, Resent-From) to indicate and track message resending by intermediaries.[47] This specification enabled more reliable propagation of messages across diverse systems, with initial implementations in Unix environments using admin-managed alias files like /etc/aliases for simple redirections before user-configurable options became widespread.[48] In Unix mail systems, such as those evolving from Delivermail in 1979, forwarding was initially handled through centralized aliasing to map addresses to multiple destinations, emphasizing system administrator control over user-driven processes.[49] These developments transitioned email from ad-hoc commands to structured protocols, facilitating broader adoption in academic and corporate networks.Evolution with user files and virtual users
The introduction of the ~/.forward file in Sendmail, released in 1983 by Eric Allman at the University of California, Berkeley, marked a significant advancement in user-configurable email forwarding. This mechanism allowed individual users to create a plain-text file named .forward in their home directories, where they could specify one or more email addresses or actions for incoming mail addressed to them. For example, a simple .forward file might contain a single line such as[email protected] to forward all mail to that address, or multiple lines like [email protected] and [email protected] for distribution to several recipients. Sendmail would process this file during local delivery, appending the specified targets to the recipient list without requiring administrator intervention.[50][51]
However, the flexibility of ~/.forward files introduced notable security implications, particularly with support for pipe commands that enabled mail to be piped to external programs for processing. A line like |/usr/local/bin/process_mail in the file would execute the specified command as the user, allowing custom filtering, archiving, or integration with other tools, but this also opened avenues for exploitation if the file's permissions were misconfigured. For instance, if a user's home directory or .forward file was writable by others, attackers could modify it to run malicious scripts, potentially leading to arbitrary code execution or file overwrites during mail delivery. To mitigate such risks, Sendmail implementations recommended strict file permissions (e.g., 644 ownership by the user) and disabled pipe usage for privileged accounts like root, often routing their mail through aliases instead.[52][53]
In the 1990s, the concept of virtual users emerged as a pivotal shift in mail transfer agents (MTAs), decoupling email addresses from underlying system user accounts and enhancing forwarding capabilities for multi-domain environments. MTAs like qmail, released in 1995 by Daniel J. Bernstein, and Postfix, introduced in 1998 by Wietse Venema, supported virtual domains through configuration files or databases that mapped email addresses to forwarding rules or mailboxes without creating corresponding Unix accounts. For example, Postfix's virtual alias maps allowed entries like [email protected] [email protected] to forward mail across domains, while virtual mailbox maps stored messages in dedicated directories, all managed centrally by administrators. This abstraction enabled seamless forwarding for non-existent or "virtual" users, treating email recipients as logical entities rather than tied to physical logins.[54]
These innovations profoundly impacted scalability, allowing service providers to host vast numbers of email users on shared infrastructure with minimal administrative overhead. By avoiding the creation of individual system accounts for each email user— a labor-intensive process in earlier Unix-based systems— virtual user support reduced resource consumption and simplified management for thousands of domains and aliases on a single server. This was instrumental in the proliferation of early webmail services and ISP-hosted email in the late 1990s, such as those offered by America Online and early iterations of Yahoo Mail, where virtual forwarding mechanisms handled surging user volumes without proportional increases in server accounts or maintenance efforts.[54][55]