Xref: utzoo comp.mail.misc:2196 comp.mail.uucp:3375 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!gatech!utkcs2!CYGNUSX1.CS.UTK.EDU!moore From: moore@CYGNUSX1.CS.UTK.EDU (Keith Moore) Newsgroups: comp.mail.misc,comp.mail.uucp Subject: Re: rewriting to's & cc's Summary: Don't rewrite message headers in transit, only on final delivery. Message-ID: <1005@utkcs2.cs.utk.edu> Date: 18 Jul 89 11:48:55 GMT References: <4291@viscous.sco.COM> Sender: news@utkcs2.cs.utk.edu Reply-To: moore@CYGNUSX1.CS.UTK.EDU Followup-To: comp.mail.misc Organization: CS Dept -- University of TN, Knoxville Lines: 94 In article <4291@viscous.sco.COM> stewarte@sco.COM (Stewart Evans) writes: >As I understand it, it is proper for transfer agents >to rewrite from: fields so that they point back to >the sender. Is it "proper" to do the same with to: >and cc: fields? It is proper for transfer agents to maintain "From " fields in message "envelopes". For UUCP, this means that every host that passes the message should prepend a "From " line to the message before passing it on to the next host or to the recipient. It's especially handy if the final delivery agent (the transfer agent that delivers the mail to the recipient) collapses the "From " lines into a return path to which replies can be sent. On the other hand, it is NOT proper for MTAs to rewrite From:, To:, or Cc: fields in message headers as long as the message remains within the UUCP mail system. One reason for this is backward compatibility: ethnically pure UUCP systems do not have headers, just an envelope and a body. Any "message headers" that were present in the original message are simply part of the message body as far as vanilla UUCP is concerned, and they are delivered intact to the recipient's machine. The addresses in the message headers of a UUCP message, if present, should then be relative to the *sender*. The address can be made relative to the recipient by prepending the envelope return path to the addresses in the message header, though this path may well be sub-optimal. The same rule is true for Internet mail systems: they should not rewrite message headers. In the Internet world, there is a different reason: all header addresses should be of the form local-part@domain, and are therefore absolute addresses. Unfortunately, many UUCP mail transfer systems do update message headers. Usually these are the ones based on sendmail. The result of this is that when someone receives a UUCP message, some of the hosts that carried the message have prepended their system names and some have not. Often this leaves the header addresses completely invalid. Fortunately, the "From " envelope address is already correct, so the final delivery agent can obtain the "From:" header from the envelope. However, the To: and Cc: addresses may need to be cleaned up if local UAs expect to be able to send replies to recipients of the original message as well as to the sender. The following idea might be useful to clean up header addresses before delivery to the recipient: Say the return path (the "From " envelope address) is a!b!c!d!tom . This means that the message passed through hosts d, c, b, and a, in that order. One or more of these hosts may have prepended its own system name to the To: and Cc: message headers. Let's say that one of these looks like a!c!d!f!joe . We can delete the "a!c!d" portion of the latter address, since they appear in the same order as the hosts in the envelope "From " address. Now we have the address "f!joe", which we cannot simply further. To this we prepend the "From " path to yield "a!b!c!d!f!joe" . Now we have a path to joe which is probably valid, and certainly closer to the truth that the To: address before cleanup. (Note: I never said this was easy to do with sendmail.) This algorithm assumes, among other things, that no message header will contain an address like ...!a!b!... if the "From " address contains ...!b!a!..., that is, no two copies of the same message pass through the same network link in opposite directions. I hope this is a reasonable assumption. Also, all bets are off if the message passes through another network, or through an MTA that tries to rewrite its headers in a more drastic fashion, before it arrives at its destination. >For example: tom at host1 sends a message to host2!dick, >and cc's harry (who is also at host1). How should that >cc: line look when host2!dick receives it? Exactly as tom typed it. >If that line >is not rewritten, then it must be the responsility of >dick's UA to determine that harry's host must be the same >as tom's, which seems pretty messy (what if there's also >a user named harry at host2, for example?). It's easier if dick's local delivery agent rewrites the headers for him before giving it to his UA. When the message is delivered locally it is leaving the UUCP system, and does not have to stay strictly within the conventions appropriate to that network. It is sometimes appropriate to rewrite headers during final message delivery, if the rewriting is necessary to adapt the header addresses to the conventions of the local UAs. -- Keith Moore Internet: moore@utkcs2.cs.utk.edu University of Tenn. CS Dept. BITNET: moore@utkvx 107 Ayres Hall, UT Campus UT Decnet: utkcs2::moore Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822