It is important to understand that the message itself, including both the headers (such as "From" and "To") and the body, can be transmitted in multiple ways other than Simple Mail Transfer Protocol (SMTP), and many of these systems, such as UUCP, were in widespread use historically. Because of this, it was important to the development of the protocols that SMTP not rely directly upon the content of the message, because otherwise this would lead to a dependency of one protocol upon the other in a way that would cascade difficulties and complexities should either need to be modified.
It is the responsibility of the SMTP sending software, which is called the Message Transfer Agent (MTA), to do any needed looking into the message in order to figure out how to route it, and then to furnish this information to the SMTP receiving software (the recipient MTA) during the SMTP exchange. In other words, all of the knowledge about how to translate between message content and message routing must be encapsulated within the MTA, thereby isolating it from the protocols themselves. Most practical MTA implementations, such as Sendmail and Exim, keep the message data and its routing information in separate files linked together in the queue by a local message identifier tag. Conceptually, SMTP is analogous to a postman looking only at the envelope rather than what is inside, and for this reason the routing information conveyed during the SMTP exchange is known as "envelope" information. Exactly how this happens is specified by the SMTP standard, the best authoritative source for which is probably RFC5321 -- https://tools.ietf.org/html/rfc5321 -- although there is also a decent Wikipedia article about it that might be much easier reading: https://secure.wikimedia.org/wikipedia/en/wiki/Simple_Mail_Transfer_Protocol Internet Message Format (IMF) is likewise specified by RFC5322 -- https://tools.ietf.org/html/rfc5322 -- although there is also a Wikipedia article about e-mail generally that contains a major section about IMF: https://secure.wikimedia.org/wikipedia/en/wiki/Email#Internet_Message_Format Typical MTAs use heuristics that may modify how they add headers to messages they carry. In particular, most MTAs are configured to state explicitly the recipient e-mail address provided by the sending MTA envelope information in writing the "Received" header they prepend, but generally will not do this if it would compromise privacy, as when the message has multiple recipients handled by the same receiving MTA. Spammers can take advantage of these practices by adding bogus recipients at the same domain or omitting the real recipient from the "To" or "Cc" headers, triggering the receiving MTA to handle the message like a "Bcc" and put less information into the "Received" header that it prepends. -- Mike On 2011-11-06 11:26, Michael ODonnell wrote: > > Yah, I had believed that the headers were consulted (rather > than merely updated) as the message was transferred from server > to server, but there's apparently some other (or additional) > conversation taking place between the servers that governs routing. > > Yet more stuff to put on my list of things-to-read... > _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
