The content of an email is actually completely independent of how email is delivered between computers on the internet. Thus the addresses you see on the To or Cc lines of an email do not necessarily have any relation to who the email was actually delivered to, and similarly, the From line of an email doesn't necessarily specify who sent the email. They have NOTHING to do with the delivery process.
All legitimate email software and systems do set the To, Cc and From lines of email to be the values the user specified for the email. On the other hand, all spam-sending software usually forges the values in these header lines to be rubbish.
So if the actual content of the email doesn't control where the email goes, what does? This is done by a separate protocol called SMTP (Simple Mail Transfer Protocol). When email is handed over from one computer ("SMTP client") to another computer ("SMTP server"), the sending computer declares a "sender address" (a. k. a. "envelope-from", which is the one non-delivery messages would be sent to if the delivery fails at a later stage) and one or several recipient addresses ("envelope-to", which designate the destination of the message that the receiving server would use to determine where to put the message). These addresses are not part of the email message, and normally they just "evaporate" - that is, they are not available to the person that receives the message.
However, we do record these two addresses in the email by adding special headers called X-Mail-from (for "envelope-from") and X-Delivered-to (for "envelope-to") to make them available to the person that receives the email (and to the filtering rules). There's another header we add as well, X-Resolved-to, that designates the final deliver address that was used for internal delivery to the user's mailbox. This address is determined by the address in X-Delivered-to using some the resolving rules described below under "What process does email delivery go through?". You can view these headers for an email by clicking the "Show full headers" link on the view message screen.
There is a legitimate case where the To and Cc lines may not list your address. That's when someone sends to you via Bcc. When someone Bcc's you in on an email, their email client uses your address in the "envelope-to" when delivering, but removes the Bcc header before sending. So if you see your address in the X-Delivered-to header but not in To or Cc in legitimate mail, it means that the sender put your address in the Bcc field in their email client.
So why is this all the case? It's basically to do with the early days of the internet, where everything was just between a few trusted university computers. No one had a need or reason to forge email headers, because people really did just want to email each other. These days of course, there are lots of people trying to push advertising on you, and they don't want their original address to be identified.
Anyone can make emails appear to come from any account; it's called "header forging" (see previous question).
There are several reasons you may have received an email from someone you don't know:
-
Someone is sending out emails to common names, or known addresses at our system. This is usually done by spammers trying to find new addresses to add to their mailing lists.
-
Someone is sending out emails to other systems, but they're forging the email to appear as if it came from you. If the address they are trying to send to doesn't actually exist, you'll get a "delivery failure" email back, even though you never sent any email to that person. Again, this is often done by spammers to hide the original source of the message, and worse, to try and give us a bad name because most users think that the "From" address on an email is accurate.
-
Someone you know has a virus, such as the 'klez' virus.
Delivered email goes through a number of steps. You can use the various transformations along these steps to help filter or understand how mail delivery occurs.
The steps are described here:
-
Email arrives via SMTP. The SMTP protocol requires two parameters during the transaction, a 'MAIL FROM' value and a 'RCPT TO' value.
-
The 'MAIL FROM' parameter is supposed to contain the email address of the sending party. If the email is from the 'postmaster' address at the remote site, an empty value of '<>' is used. The value used here is completely independent of what is shown in the actual email header 'From' line.
-
The 'RCPT TO' parameter specifies the recipients of the message. The value used here is completely independent of what is shown in the actual email header 'To'/'Cc' lines. This is how emails which are Bcc'ed to you, or with forged headers (see first question above), can arrive at your account even if your address is not in the header.
-
-
Any aliases, Virtual Domains and subdomains are matched and translated to the 'Target' values. This is done repeatedly until no more translations occur. The order is as follows:
-
Any address of the form name@subdomain.srcdomain.com is translated to subdomain+name@srcdomain.com . Note: Some people get the order here confused. If you have an account called 'youraccount', then you can use <anything>@youraccount.actdomain.com and it will be delivered to your account.
-
For an address of the form name+plus@srcdomain.com , if an alias/virtual alias name@srcdomain.com exists, then the address is replaced with the 'Target' of the alias.
-
If address contains a '+' part (e. g. name+srcplus@srcdomain.com ) and the 'Target' also contains a '+' part (e. g. target+trgplus@trgdomain.com ) then the two are combined into target+trgplus.srcplus@trgdomain.com .
-
If no specific name@srcdomain.com virtual alias exists, but a 'catch all' virtual alias exists (e. g. *@srcdomain.com ), then the target of that is used. If the 'Target' contains an asterix (*) in it, between the '+' part and the '@' part, then it is replaced with the original name part of the address. For instance:
-
The virtual alias *@srcdomain.com exists with a 'Target' of yourname+*@trgdomain.com
-
Then an email sent to john@srcdomain.com will be rewritten to yourname+john@trgdomain.com .
-
If you have a folder in your account called 'john', then this email will automatically be filed straight into that folder. You can also deliver straight to a subfolder by using a 'Target' of yourname+parentfolder.*@trgdomain.com
-
-
If the 'Target' contains commas, then it is separated on the commas into multiple target values. Each of the actions described above occurs on each of the target addresses.
-
-
If the resultant target (or targets) is an external address, the email is then queued for sending to the external address.
-
If the address is local, it is delivered to the appropriate local mailbox. During delivery, the following also occurs:
-
The original SMTP 'MAIL FROM' parameter is added to the email as an 'X-Mail-from' header.
-
The original SMTP 'RCPT TO' parameter is added to the email as an 'X-Delivered-to' header.
-
The result delivery address based on the alias and subdomain translations above is added to the email as an 'X-Resolve-to' header.
-
If the email has any attachments, the names of the attachments are added as 'X-Attached' headers.
-
If the user has virus checking enabled and the email has any attachments, the email is virus scanned and actions as specified on the users Spam/Virus preferences screen are taken.
-
If the user has spam checking enabled, the email is spam checked.
-
Any SpamAssassin "hits" are put in the 'X-Spam-hits' header. See SpamAsassin Tests for a list of the main tests performed and their scores.
-
A "spam score" is put in the 'X-Spam-score' header. It's clamped to be always >= 0, even if the actual score was negative.
-
-
-
After that, the users "sieve script" is run on the email. This is a script generated from the Options -> Define Rules screen which controls the discard/bounce/file-into-folder/forwarding actions for the email.
-
If the final delivery address has a '+' in it, and no particular sieve rule catches the email to file into a specific folder, then the email is delivered to the folder name after the '+' part. Folder names are matched case-insensitively, and with the characters '_', '-', and the space character all being regarded as the same. E. g. email to username+sent_items@domain.com will be placed into the "Sent Items" folder. If no such folder exists, then the email will deliver to the standard Inbox. You can deliver to subfolders by using '.' to separate folder names.
-
The 'envelope' value seen by the sieve script is the resultant target value, not the original 'MAIL FROM' or 'RCPT TO' parts.
While your email is being processed, a number of headers are added:
-
X-Spam-score: is a number greater than or equal to 0. It is the score assigned by SpamAssassin , after any adjustments have been made. It will not have more than one decimal place. This header is used by the normal spam filtering.
-
X-Spam-hits: is a list of the SpamAssassin tests that this message triggered. Definitions of these tests can be found at SpamAssassin's tests page .
-
X-Spam: (deprecated) can be "high" or "spam". If the SpamAssassin score is greater than the threshold you have set for subject marking, this will be "spam". If the score is greater than twice that threshold X-Spam will be set to "high". This header is only present for compatibility with old sieve scripts. It is better to use X-Spam-score instead.
-
X-Attached: One of these headers is added for each attachment. The value of the header is the name of the attachment.
-
X-Mail-from: is the sender address from the original SMTP envelope.
-
X-Delivered-to: is the recipient address from the original SMTP envelope (i.e. the email address the sender actually sent to).
-
X-Resolved-to: is the final recipient address, after any address rewriting, and after aliases have been resolved. It is added at the LMTP delivery stage.
-
X-Spam-known-sender: is set to "yes" if the sender of this message is in the recipient's address book. This can be useful to whitelist email from your friends. X-Spam-known-sender is added at the LMTP delivery stage. This header is used by the normal spam filtering.
-
X-Spam-orig-subject: if spam subject marking is enabled, then this header contains the original value of the Subject header before any marking was applied. It is added at the LMTP delivery stage.