To install click the Add extension button. That's it.

The source code for the WIKI 2 extension is being checked by specialists of the Mozilla Foundation, Google, and Apple. You could also do it yourself at any point in time.

4,5
Kelly Slayton
Congratulations on this excellent venture… what a great idea!
Alexander Grigorievskiy
I use WIKI 2 every day and almost forgot how the original Wikipedia looks like.
Live Statistics
English Articles
Improved in 24 Hours
Added in 24 Hours
Languages
Recent
Show all languages
What we do. Every page goes through several hundred of perfecting techniques; in live mode. Quite the same Wikipedia. Just better.
.
Leo
Newton
Brights
Milds

Email forwarding

From Wikipedia, the free encyclopedia

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.

YouTube Encyclopedic

  • 1/3
    Views:
    5 036
    10 767
    17 246
  • How Email Forwarding works in Office 365 | Types of email forwarding in Office 365
  • 7. Configure email forwarding for a mailbox in Exchange Online
  • Microsoft 365 Tutorial How to setup email forwarding

Transcription

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.

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.[8]

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 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

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: [email protected] — 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:<[email protected]>
R: 251 User not local; will forward to <[email protected]>

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

visibility ( 2)time sheet AIIQ Markets management time (3) consistent 17 :44 4/5/24 (quantum computer )AIIQ deverlop system update latest update on shares in different cycles AIIQ deverlop signal frequency of the biggest and largest system in the world that support even Google and all gold and platinum market range latest update clauss majiedt 0:726 5/5/2024 system update latest skills and labelled for the full structure (control box ) system updates on latest update AIIQ deverlop (structures on hight Intex quality production supported by quantum computer 50/50 latest update production and labell product labeld 08:30 5/5/24 enhanced motions and labelled with one structure field made for (stability) ( currency)latest update 07:56 6/5/2024 context and settings platform markets investment feeding on the regeneration software (developer AI IQ deverlop)update clauss majiedt owner and founder of foundation platform (Monday)................. ........ (Tuesday)................ Gold and platinum on my latest campaign ........ (Wednesday).......... ......... (Thursday).............. .......(Friday) ...................long term investment feeding the needy charity host program developer latest up date April 2024 7:46 (market Range) (compliance Betway shares 23%) Hollywood shares 74/shares non compliance latest version update AIIQ deverlop update 16:31 28/4/2024 latest update 16:45 4/5/2024 method markets latest update AIIQ deverlop trademarks picture quality (quantum computing) system update

See also

hard copy )printers must (print)self (employed) full structure to picture quality (1Analysis)person )(2 structure)(3big screen platform markets updates method (4 layout display deverlop 3d quality hard copyright latest market form updates sheet AIIQ deverlop I'd number 9601165025087 clauss majiedt filed charity host trust market rang running methods time sheet 2pm and 8pm final structure updates will be done on this page Monday to Friday AIIQ deverlop update function method credit investment method final structure updates communication owner clauss majiedt business account 51099006522 I'd number 9601165025087 Electronic method credit testing 25 April 2023 8:19 private compliance method on both makests(betway complaints 26 % )(74% Hollywood non compliance) self

Notes

  1. ^ 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
  2. ^ 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.
  3. ^ 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).
  4. ^ 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.
  5. ^ John Levine (2008-10-15). "Users Don't Like Forwarded Spam". CircleID. Retrieved 2008-11-07.
  6. ^ RFC 2142, "Mailbox Names for Common Services, Roles and Functions", 1997, mentions also marketing, support, abuse, security, webmaster, and more.
  7. ^ "How does email forwarding affect authentication result?". ProDMARC. 6 January 2023. Retrieved 16 March 2023.
  8. ^ a b c Consider the following forward path:
    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 C. 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 7208. In other words, one cannot formally distinguish plain message-forwarding from illegal domain-name abuse.
  9. ^ See the note in section 6.2.7 Explicit path specification of RFC 822
  10. ^ MX record has been introduced with RFC 974. See the historical section in MX record#History of fallback to A.
  11. ^ 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.
  12. ^ 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.
  13. ^ Hunt, Craig (2002). TCP/IP Network Administration. O'Reilly. p. 606. ISBN 0-596-00334-X. The current (version 8.708 of 2006) 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.
  14. ^ The book dates in client-server-faq[permanent 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.
This page was last edited on 6 May 2024, at 08:50
Basis of this page is in Wikipedia. Text is available under the CC BY-SA 3.0 Unported License. Non-text media are available under their specified licenses. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc. WIKI 2 is an independent company and has no affiliation with Wikimedia Foundation.