Dan's Mail Format Site:

Headers: From / To / CC / BCC

Where did it come from, and where did it go? Those are the questions that are answered, where an e-mail message is concerned, by the From, To, and CC headers... at least when they're not forged! A message can also go to addresses in a BCC header, but the recipients can't see that. Here's some information on these important headers.

About E-Mail Addresses

The contents of the From, To, CC, and BCC headers are syntactically identical: each consists of one or more e-mail addresses. Normally, the From header will have only one address in it while the other headers might have multiple addresses, but the standards actually permit even the From header to have more than one address in it, though this is seldom seen.

Let's start with the simplest thing that can go into an address header, a single e-mail address. (We'll get into the more advanced things, like multiple addresses and addresses with names, later.) You probably already know that an e-mail address commonly looks like this:

jsmith@example.net

Mailbox Names

The thing to the left of the at sign (@) is a mailbox name, which is often (but not always) the same as the username or userid the recipient uses to log in to the server (don't call it a "screen name"; that brands you as an AOLer!). It could also be a mail alias that forwards to a different username, on the same server or a different one. Only the server to which it's sent knows whether a particular name is valid and to whom it goes; there's no universal Internet standard of mailbox naming (though there are a few names, like postmaster, that are recommended by Internet standards to be active at every host).

Hostnames

To the right of the at sign is a domain name or hostname. In the "old days", when most e-mail users got their mail by logging into a big multi-user timesharing computer with a "dumb terminal", then running a mail program on the remote computer from the command line, the hostname usually named the specific computer they were logging into, and might have several dots in it representing levels of subdomains, like vaxb.cs.example.edu. Nowadays, however, people usually get their mail on their own personal computers using programs (either a mail program or a browser connecting to a webmail interface) that connect to a mail server, and the addresses have a simple domain name like example.net without a server hostname in it. This is accomplished by the DNS (Domain Name System) feature called "MX records" (for "Mail eXchange"), allowing a domain name to be associated with a mail server that handles mail to addresses in that domain, possibly a different server than is used for other Internet activity (e.g., Web sites) at that domain. Really high-traffic domains, like aol.com, might have lots of different servers, for both Web and e-mail, with the DNS configured to go in a load-balancing rotation between them, invisibly to the user. It's still possible, however, to name a specific server in an e-mail address, and this is sometimes done by "techies" setting up inter-server communications. You can even use a raw IP address (the numeric addresses that underly the Internet but are usually not seen by end-users because the domain name system shields them from these), but it must be surrounded with square brackets like: user@[127.0.0.1]. (Note: 127.0.0.1 is the special IP address that's equivalent to localhost, meaning that you'd be trying to send mail to your own computer if you used this address.)

Abbreviated Addresses

People can sometimes get away with leaving out parts of an e-mail address for "local mail" within one system or network (just as you can, in most places, dial a local phone call without including the area code). If the part of the destination to the right of the at sign is exactly the same as the hostname of the server to which you're connecting to send the mail (e.g., you're connecting to mail.example.net and the address is user@mail.example.net), it'll usually work to leave out the at sign and the stuff to the right of it and just send to user. It might also sometimes be possible to leave out parts at the right end of the domain name; if you're on a university network, sending your mail through a server within the example.edu domain, you might be able to send mail to joe@cs.example.edu by typing the address as joe@cs. These things were much more common back in the days when people did their e-mailing on big multiuser mainframes, and many of their messages were "local" to the same machine or another one in the same local area network. Now that most people connect to remote ISPs, this is much less likely to be useful (except within a few big online services like AOL, where you can leave out the @aol.com part when e-mailing other users on the same service). It's generally best to use the full form of an address, even when you can get away with something shorter, since you know this will always work no matter where you're sending from. Anyway, a message might later get forwarded somewhere outside the local network, where an abbreviated address will be meaningless.

As another form of abbreviation, many mail programs let you type a name or nickname into an address field in order to send to the corresponding person. This can be a dangerous feature if the program doesn't show you the actual address it's sending to and give you a chance to change it before actually sending; many people have unintentionally sent private things to the wrong person, or even to an entire mailing list, to their embarrassment. It's even possible for a mail program to get the mistaken idea that a full, correct e-mail address, like user@example.com, is actually an alias that "really means" some other address or set of addresses entirely, depending on what happens to be in your address book. Not very surprisingly to me, Microsoft programs are particularly prone to this sort of thing. So be very careful who you're sending to! Nonetheless, this has no impact on mail header syntax, because the mail program must convert such "shortcuts" to the actual address to send to, and put this address in the headers, before transmitting the message.

Common Errors in Addressing

Unfortunately, Internet users these days aren't particularly good at typing an e-mail address correctly, whether it's one they're trying to send to, or even when it's their own address which they're trying to type into a Web form or their e-mail program's configuration. In both my personal and work experience, I've had to deal many times with the problems caused by faulty e-mail entry, when customers and Web site users just can't get it right.

One particularly rampant error these days is to put www. at the beginning of an address -- if you tell a customer to send mail to customersupport@example.com they just might type www.customersupport@example.com, and they'll do the same to their own address when asked to type it in a Web form. This seems to come from confusing Web addresses with e-mail addresses (though Web addresses needn't start with www. either). While it's perfectly legal by the standards for an e-mail address to have www. at the start of its mailbox name, very few of them actually do; nevertheless, people keep on thinking they ought to anyway.

Another common error is to put spaces and punctuation in the middle of the address -- e.g., if your username is johnsmith, typing it as John Smith -- yes, that's how you type the name in plain-English documents, but as a mailbox name it is generally one word. (As I'll show later, there's actually a way to get spaces into the middle of perfectly legal e-mail addresses, but that takes some special syntax.)

Still another error is to leave out all or part of the hostname portion of the address. AOLers especially do this, omitting the @aol.com part, or typing it as @aol without the .com. As I showed above, there are some instances when it's acceptable to omit all or part of the hostname; sending mail within an online service is one of them. However, when entering your address in a Web form, where a program is going to have to send mail to it from an unknown part of the Internet, you must give it a fully qualified address.

Be sure to find out exactly what your e-mail address is (ask your ISP if you're not sure), and type it in correctly every time you need to provide it. And be sure you pay careful attention to anybody else's e-mail address you want to send to, in order to remember and type it correctly. You'll save yourself, and your recipients, much grief.

Address Validity Checking

Because of the above-mentioned problem of widespread errors in e-mail address entry, many sites make a variety of validity checks before accepting a user-supplied address on a form. Unfortunately, this too can cause problems if not done well. There are plenty of cases where perfectly valid addresses get rejected due to improperly implemented "validity checks". RFC 3696 covers this issue.

One type of valid address that's sometimes improperly rejected is an address using one of the new top level domains that is four or more letters long, like .name or .info. Since, prior to the introduction of the new TLDs in 2001, no top level domain was longer than three letters (other than the infrastructure domain .arpa which is not used in e-mail addresses), it was considered "safe" to reject as invalid any address that had four or more characters to the right of the last dot. Unfortunately, some sites continue to do this even after there are valid addresses that don't pass this test, including the .name domain which is specifically intended for personal e-mail and Web use.

I'm using a .name address myself, and have run into a few sites that have a problem with it. In those cases I attempt to do "tech evangelism" to convince the site that they have a problem that should be fixed (similarly to the tech evangelism campaigns done by the developers of the Mozilla browser to convince webmasters whose standards-noncompliant sites don't render correctly in Mozilla to fix them). I don't always succeed; some of the sites seem to be pretty obstinate that four-letter top level domains should be rejected. For instance, Cingular won't accept such domains in their site for customers to request their cell-phone bills be sent by e-mail instead of paper; I had a long argument with one of their customer service reps about it, who was well aware that .name domains exist, but still said that Cingular had no intention of supporting them because "hardly anybody uses them," and thus, a "better customer experience" would be provided by their continuing to reject them because if anybody types anything that weird, it's more likely than not to be an error. (They did, however, manually change my address to my desired .name value, which they can do from their console; but they refuse to change their public interface so that other .name users can enter their addresses themselves.)

Another site that wouldn't accept the address is the signup page for the "Anything Points" promotion at Ebay, and my attempts to complain about that hit a bureaucratic maze of twisty little passages, all different. The customer-service Web form in that site yielded a canned response saying I had to go to PayPal's site and use their customer service form; that, in turn, yielded a canned response saying that I had to go to EBay and use their form; and that gave a canned response saying that they're having temporary server problems and I need to wait a while and try again. None of these responses gave the slightest indication that any clueful human being had ever actually read my complaint, and weeks later, their site still won't accept my address.

The lesson here is to be very careful when programming address validators, to ensure you don't end up unnecessarily turning away customers. This site has an example of the sort of "validation" you don't want to use; it rejects my .name address.

Baby, remember my name...

I mentioned that you can include a name as well as an address. It's done like this:

"John Q. Smith" <jqsmith@example.net>

The name (with or without quotes around it) is followed by the address enclosed in angle brackets. The quotes are required if the name has anything other than letters, numbers, and a few other permitted characters. I used to mistakenly believe (based on a misreading of the RFC) that, if there's a space in the name (as there usually is except in the case of pop stars who go "surnameless"), you must put quotes around the name. This is not the case; multi-word names are allowed without quotes, though if you include punctuation such as commas or periods, then the quotes are required; hence, in the above example, you need the quotes because of the period after the initial "Q". It's never invalid to include the quotes even if they're not required in a given case.

Another form of name-and-address combination that's sometimes encountered looks like this:

jqsmith@example.net (John Q. Smith)

This makes use of the feature in the standards that lets parenthesized comments be inserted into headers. Hence, "John Q. Smith" in the above line is a comment, which should properly be ignored by programs that process the message. Most mail programs, however, treat a string in this position as a person's name, to be displayed in the same manner as one in the more proper format of the previous example.

Usually, of course, the end user does not type any of these formats into their mail program when sending a message; they rely on the program to generate it somehow. In the From header, the personal name will usually be taken from a configuration item where you can supply the program with your own name. In the other headers, a personal name might be taken from your address book -- so you should probably refrain from using address-book names like "That Moron in the Marketing Department", as fun and cathartic as this may be, because your program might just insert them into messages where the person being addressed can see them. When replying to a message, the name may be taken from the headers of the original message. However it's obtained, the name is then inserted into a header line, hopefully (but not inevitably) in a standards-compliant way.

Note: One thing that will put you at risk of having your mail program inflict nonstandard header lines on your messages is to attempt to include quotation marks within your name, like Jesse "The Body" Ventura. If inserted directly into the header, within double quotes, you'd get "Jesse "The Body" Ventura", which actually parses into two quoted strings, "Jesse " and " Ventura", with The Body sitting in the middle with uncertain purpose. The correct way to include quotes within quotes would be to put a backslash before each of the inner quotes, like "Jesse \"The Body\" Ventura". Well-behaved mail programs ought to insert the backslashes when sending messages with such names, and remove them when displaying the name to the recipient. However, you can't count on mail programs being well-behaved, so if you type in "naked" quotes, they may be sent as-is (violating the standards); and if you insert backslashes (by hand if necessary), this may cause some of your recipients to see the name with backslashes in it, which is rather ugly. It's best to avoid the double-quote character within names; use a single quote (') instead: Jesse 'The Body' Ventura. (And don't use so-called "smart quote" characters, discussed further in the article on character sets; they're not part of the standard ASCII character set.)

When displaying a message, various programs deal with names and addresses in different ways. Some of them (particularly those from Microsoft, which like to hide "technical details" from users) tend to show only the personal name, and not the associated address; this can cause problems (such as people sending messages without knowing who they're actually sending to, as with the address-book shortcuts noted above). Sometimes a forwarded message will have its headers mangled in this way -- I've sometimes received messages that have gone through one or more "hands" before reaching me, in which the name of the original sender is shown, but no address at all -- and the message tells me that I have to send some sort of reply to the original sender, something that I have no way of doing. Very annoying.

Perhaps to try to get around this problem, I've occasionally observed mail programs using a bizarre "double-addressed" form like this:

"John Q. Smith <jqsmith@example.net>" <jqsmith@example.net>

Yahoo Groups did this for a while when you sent messages through its Web interface, though they gave it up eventually, apparently not wishing to keep on in one of those counterproductive "arms races" that periodically break out (the ongoing fight between webmasters cluelessly blocking browsers based on user-agent string sniffing, and browser makers making their user agent strings "spoof" more popular browsers, is a good example of such a race). If the battle were to be seriously joined, one would expect Microsoft to release a new mail program that parses out the second embedded address too, leaving only the name once again, and then Yahoo responding by finding a way to embed a third copy of the address.

I've also, on a few occasions, seen addresses with different e-mail addresses in the name section, like:

"jjones@example.org" <ksmith@example.net>

This usually indicates either an intentional scam (they're trying to make you think the message came from jjones@example.org when it really came from ksmith@example.net) or a bizarrely misconfigured mail program. It's rather confusing at any rate.

When you're having more than one...

If you need to put more than one e-mail address in a header, for instance when you wish to send a message to several people at once, the addresses are separated with commas, like this (with "simple" addresses):

jsmith@example.net, mjones@example.org

Or this (with names and addresses):

"John Smith" <jsmith@example.net>, "Mark Jones" <mjones@example.org>

The space after the comma is optional, but improves the readability. (The whitespace characters, space and tab, are allowed before or after each address within a header.)

Note that the comma (,) is the proper separator between multiple addresses, not the semicolon (;) or any other character. There are some mail programs that display lists of addresses with semicolons, and accept this format when taking input of addresses, but any standards-compliant program will actually use commas when transmitting the address list in a message header. There are reports that some mail programs launched by Web browsers in response to mailto: links require lists of multiple addresses within such a link to be separated by semicolons (and choke on comma-separated lists), while others are the opposite way; it is for reasons like this that it is not recommended that you use anything other than a single address in a mailto: link, even if there are standards documents allowing more complex values.

The From Header

Now that we've given the syntax of addresses as used in headers, describing the specific headers is pretty simple. The From header indicates who the message came from. Or, it does in theory... in practice can be another matter. Since a mail program can be configured to put anything the user wants in this header, it does not necessarily have to be the actual address of the originator of the message. There's no security built into the mail protocols to prevent the forging of addresses in mail headers. People will normally use a correct From header (unless they messed up and misconfigured their mail program), but there are plenty of cases where incorrect addresses are used -- for instance, spammers (bulk unsolicited commercial e-mail senders) usually use fake return addresses so they don't have to be troubled with bounced messages or complaints about their spam, and viruses often forge their originating address as well. So you can't always be sure that a message really came from whom it claims.

Address Munging

Regrettably, there's a growing trend for normally-honest people to intentionally make their e-mail address unuseable as written... usually not in the "From" field of regular e-mails, but in things like newsgroup and Web forum posts. This practice, referred to as "munging", is done to avoid spam "harvesters" that lift addresses from such places to add to their spamming lists. Unfortunately, it also creates a pain-in-the-butt for legitimate correspondents who wish to make contact. Use of a false return address in either e-mail or newsgroups is against the Internet standards, and is basically doing the same thing that spammers themselves do when they falsify their return addresses. It's something I refuse to do myself; every Web page and newsgroup posting I make has a valid e-mail address on it, even though I know this means I'll be deluged with spam (most of which I manage to filter with my mail program's filtering rules). I also refuse to jump through hoops to de-munge addresses of others; if they won't provide a valid address in their site or posting, I won't even try to contact them by e-mail.

Sometimes I've found cases of people "munging" their address within a newsgroup or e-mail list message, like "...If you have any opinions about this, email me at johndoeMYSHIRT@example.comMYPANTS -- remove my shirt and pants first." -- but at the same time their messages were posted with their full, untrammeled email address in the FROM line of the message as configured in the mail or news program they used to post it. This makes the "munging" in the message body completely pointless and just makes the writer look silly. Similarly, there are plenty of cases of people putting variously-munged addresses in the visible text of a Web page or blog/forum/wiki entry, but hyperlinking it to a completely un-munged mailto link to the address.

However, the silliest "address munging" I've seen is in the text of articles in print publications -- that is, on paper. Does the author think that spammers will use OCR scanners to harvest their address? Actually, the likely cause is that articles are often written for both electronic and paper publication, and the author wasn't taking any chances of letting his un-munged address get online, even if this had the side effect of silliness in the paper version.

Addresses that Aren't Munged, but Look Like It

Occasionally, somebody will attempt to do something "cleverer" than address-munging; they'll aim to come up with a perfectly valid address that looks invalid, so that spam harvesters ignore it. As I've said above, something as simple as using an uncommon top level domain like .name can be enough to throw some programs for a loop, but people can get more sophisticated than that; the address-format standards allow for lots of seldomly-used oddball stuff including the use of characters not commonly found in addresses (some of which require the use of special quoting and escaping rules involving quotation marks or backslashes). Here, for instance, is an actual address that has been used by a person who has nicely granted me permission to publish it here:

"Guy Macon" <guymacon+" http://www.guymacon.com/ "00@spamcop.net>

The plus sign, quotes, spaces, colon, and slashes are all part of the mailbox portion of his address, which is handled by a server that is set up to allow users to put whatever they want after a plus sign and deliver it to the mailbox named prior to that sign, but allow spam-filtering rules to operate based on the contents of the part after the plus. He regularly changes his address (the "00" gets changed based on the current year) and spam-filters obsolete versions of the address, so even if a spam harvester actually accepts his dubious-looking address, it stops working eventually. (This "plus" trick actually works on many servers these days, since it's a standard feature of newer versions of the Unix sendmail program.)

It may, however, be hard to convince legitimate correspondents that such a weird address is actually real, or to get them to type it in correctly when they attempt to use it.

Another thing you might, on rare occasions, see in an e-mail address is a percent sign (%); this indicates a message intended to be forwarded to its destination by another server instead of being sent directly. This was more common in the "old days" when there were lots of computer networks that weren't directly on the Internet but could be reached via gateway systems; you might send to user%example.theothernet@gateway.example.net, where the actual non-Internet destination address is user@example.theothernet (in those days, many networks used pseudo-domain-style addresses ending in things like .bitnet or .uucp even though no such top level domains existed on the Internet) and the messages got there by way of gateway.example.net. Now that pretty much everything is directly connected to the Internet, you don't see percent-sign-based addresses very often, but it's still a legal syntactic form and might have specialized applications. The stuff after the percent sign and before the at sign might be in a very un-Internet-like format as might be needed for a remote network; for instance, the Unix-based UUCP network traditionally used what they called "bang paths", consisting of a string of node names separated by exclamation points, like this!that!other!theend; the message would get passed in turn to each server on the list, in the order stated, finally getting to the destination at the end (maybe days later).

Why's There an Angle Bracket Before a "From"?

Perhaps you've noticed this in an e-mail message occasionally. You reach a point in the message where the word "From" appears at the beginning of a line, and it's inexplicably got an angle bracket (greater-than sign) before it, like this:

The lyrics go like this:
>From the halls of Montezuma
to the shores of Tripoli...

Usually a greater-than sign at the start of a line signifies quoted material (and, if your mail program shows quotes in a different color from other text, it might have even colored in that line above), but in this case the line with the angle bracket is not quoted from another message; it's new material. So why is the angle bracket there? A weird typo? No, certain (mostly Unix-based) mail server programs will insert the greater-than sign before a leading "From", to "protect" it from being interpreted as a header. But the header which it's in danger of being misinterpreted as is not the From header described above; it's something used by the traditional Unix mailbox format. Unix messages are traditionally stored in flat text files, one message after another. At the beginning of each message, the server inserts a line that starts "From", and is followed by the server address the message was received from and the date it was received. Programs that need to process a mailbox full of messages have to know where one message ends and another begins, so they look for this "From" line (which can be distinguished from the normal From header because that has a colon following the word "From", while the mailbox header has a space). As a result, Unix mail programs will purposely alter any line starting with "From" followed by a space, by putting a greater-than sign before it, so that it doesn't get detected as the boundary between two messages.

This was a rather poor design decision by whoever created the Unix mailbox format in the first place; when they chose a boundary marker, they should have picked something much less likely to turn up in the middle of a message than a common English word like "From". But we seem to be stuck with it now; even if you don't get your mail from a Unix server, it's likely to be "mangled" by some server it passes through during its route from sender to recipient anyway. It just goes to show that Microsoft and AOL don't have a monopoly on inflicting screwy and annoying "standards" on the computer world; even the Unix geeks have done some of it.

The To Header

The person or persons the message is intended for is/are addressed in the To header. Pretty straightforward. However, like the From header, this can be forged or incorrect. The mail transport protocols have commands by which the destination address is communicated to the server independently of the mail headers, so a message may actually wind up in a different place from where the headers say it's supposedly destined, if the originating program told the server to send it there. You'll often find that you get messages in which your address doesn't appear in the To header. People sometimes do spam-filtering based on the absence of their own address in the headers, as it generally indicates a bulk mailing; however, this will also filter out some sorts of mailing lists you may have intentionally subscribed to (unless you add special exceptions for them), and won't filter all spam (since some of it is personally addressed to you; an increasing amount lately, in fact, due to a desire by the spammers to get around such filters).

The CC Header

The CC header really works just like the To header; it indicates that the message is sent to the addresses in it, too. The difference is that if you're in the To header it means the message is aimed specifically at you, while if you're in the CC header it just means that you're being copied on a message aimed at somebody else. It's more of a social distinction than a technical one. "CC", by the way, stands for a piece of archaic, pre-computer technology: Carbon Copy.

The BCC Header

The BCC header works like the CC header, indicating that the message is to be copied to all the addresses on this list, except that this is a blind copy: the recipients aren't supposed to know who else the message is being copied to. This means that the server is supposed to strip out the BCC header before delivering each copy of the message. Only the sender gets to see the contents of this header. But remember that nothing is truly private or secure on the Internet unless it's sent end-to-end by encrypted protocols; just because you cause the messages to omit mention of the other recipients doesn't mean that somebody, somewhere, won't purposely or accidentally discover who you sent the message to. If there are bad addresses on the list, for instance, the message might get bounced to the server's postmaster.

In addition to privacy and security, the BCC style of sending is sometimes used when sending to long lists of addresses in order to prevent the headers from being longer than the message itself, wasting bandwidth and disk space and (in some mail readers) forcing a lot of scrolling down to get to the actual message content. Also, if one of the recipients selects "Reply To All" when responding, the reply would go to everybody on the list if they're in a normal To or CC header, but not in a BCC header (because the recipient doesn't even have that header to send to). I've been an unfortunate recipient of cascades of messages that result when something unexpected is sent to a long list, some of whom "Reply To All" to complain that the first sender is "spamming" them, causing more unexpected messages for all the other recipients, some of whom "Reply To All" in turn. That can be really unpleasant.

Other Related Headers

There are a few more address-related headers:

Sender: Supposed to be used to indicate who actually sent the message, if different from the address in the From header, but just as capable of being forged. Sometimes mail servers might insert the actual username and mail servername from which the message originated, for tracing purposes. Since this may not be an actual usable reply address, and some mail programs might try to reply to this field, some programs have taken to using X-Sender instead of Sender to hold the server account info; but since there are a few mail programs that recognize this and might still try to send to it, a few servers have gone even farther (in yet another of those interminable arms races) and used X-X-Sender.
Return-Path: An attempt to indicate where the message came from for the purpose of letting other mail transport programs know where to send bounce messages; this may be different from the From and Sender headers, especially in the case of mailing lists where the message is sent out by a list server, with the server's address in the return path, although the From address still indicates the human writer of the message. But this, too, can be forged, and probably is in the case of a spam message. Errors-To is yet another header sometimes used to indicate the proper place to send errors resulting from attempts to deliver the message; mailing lists sometimes use it.
Reply-To: Indicates where the sender wishes replies to go to, if different from the From address. They may be sending from a different address from the one they usually use, but wish replies to go to their normal address, or it may be a mailing-list message that's indicated as being from the individual sender but replies are directed to the entire list (or vice versa). (Flame wars have broken out on some mailing lists over which way replies should be directed by default; some refer to the insertion of a Reply-To address by list software as "Reply-To munging", not to be confused with the anti-spam address munging discussed above. I, myself, prefer replies to be directed to the list, as I usually want to reply publicly to continue the discussion for the benefit of all, and this can be a pain when replies are directed only to the individual sender.) Your mail program probably has a configuration field to set the value of this header. Leave it blank if you want replies to go to your normal address. Unfortunately, there have been some mail programs out there which default this field to a bogus value, like @example.net (with nothing to the left of the at sign) when your From address is user@example.net. The program author apparently expected you to go through the configuration settings and fill in something to the left of the at sign, but if you don't, it stays in this problematic default where anybody who tries to reply to you gets their replies directed to an invalid address.
Resent-From, Resent-To, Resent-CC, Resent-BCC, Resent-Sender: Used just like the corresponding From, To, CC, BCC, and Sender fields, but inserted when a message is forwarded in a manner that leaves the original headers intact when sending it on to its new destination. The Resent- headers indicate who the forwarder and forwardee(s) are. The message shows up as being from the original sender, but the final recipient can find out who forwarded it by viewing the full headers if the forwarding headers aren't shown in the normal message view.