|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T p
Length: 8713 (0x2209) Types: TextFile Names: »part.2«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit └─⟦2fafebccf⟧ »EurOpenD3/mail/smail3.1.19.tar.Z« └─⟦bcd2bc73f⟧ └─⟦this⟧ »design/part.2«
Part 2: Cleaning up a header. Headers for mail originating at the local site should be in reasonable conformance to RFC822 before being sent. To do this, some conventions used by users and by some mail user agents need to be cleaned up. These generally involve making addresses in headers conform as much as is reasonable, making sure that addresses are cleanly separated when multiple addresses appear in one field, and ensuring that all required header fields exist. This last part must be done for all mail, not just mail originated locally. Section 2.1: Which header fields contain addresses to be cleaned Given one interpretation of RFC822, we must either cleanup the following headers: Resent-Sender: Resent-From: Resent-To: Resent-Cc: Resent-Bcc: or we must cleanup the headers: Sender: From: To: Cc: Bcc: the former list will be used if any member of the list exists. Thus, previous to cleanup, a scan must be made of the headers to determine the set to cleanup. In the following sections, any reference to an above header without the ``Resent-'' prefix should be applied to the ``Resent-'' version of the header under the condition stated above. Note: A Bcc: header field should be removed from locally generated mail before being delivered. It is a ``Blind Carbon Copy'' after all, so it doesn't do any good if other people can see it! Optionally, it could be left in headers for copies sent to people referenced in the Bcc: line. Section 2.2: How to cleanup addressing header fields. The following headers must be created if they do not exist: From: <from_address> To: <to_address>(, <to_address>)* where: <from_address> = address of the originator <to_address> = a appointed recipient of the message In addition to this, either the ``From:'' or a ``Sender:'' field must exist that correctly states the address of the user sending the mail. A local user cannot specify a Sender: field himself, and any attempt to do so will be replaced by a field filled in by the smail. A created ``From:'' or ``Sender:'' field should contain the address of the sender of a message in the form: From: <user>@<domain>[ (<full_name>)] or Sender: <user>@<domain>[ (<full_name>)] where: <user> = the mailbox id of the sender. A From: field created for a message where the sender is known only as a return path should use the !-route return path here. <domain> = the fully qualified name of the local domain. <full_name> = the full name of the sender, if known. If this is not known, the optional part of the field should not be included. On locally originated messages, addresses that are not fully qualified addresses should be transformed into fully qualified domain addresses. Hosts that are not reachable within the context of a local domain should be qualified in the UUCP domain. It is an unfortunate difficulty that users and programs who generate mail do not generally put commas between addresses in header fields. Thus, an important part of cleaning up these fields is to identify correctly the boundaries of addresses and put commas between them if commas do not exist already. Example: Given the following two header fields from a message, where tron originated the message from a machine in the domain ``kremvax.kgb.comm'', and where ``kgbvax'' is another machine in the ``kgb.comm'' domain and ``rsrch'' is a subdomain of ``kgb.comm'': From: debbie (Debbie McCormackov) To: les@glotz gorbie him@kray.rsrch her@kgbvax These headers should be transformed into: From: debbie@kremvax.kgb.comm (Debbie McCormackov) To: les@glotz.uucp, gorbie@kremvax.kgb.comm, him@kray.rsrch.kgb.comm, her@kgbvax.kgb.comm Note that changing white space in a header field should be done only if the changed header field is longer. Example: Given the following header with the same context as the previous example, and ``moscvax'' being a machine in the local domain (``.kgb.comm''), and with ``nsavax'' being a machine in ``nsa.gov'': From: sys-op-group: gavrilov (A.I. Gavrilov), smirnov (Z.Z. Smirnov), debbie (Debbie McCormackov); To: edm@burbank.nbc.com, kgbvax!glotz!namei!chongo Cc: brown@nsavax, gorbie@moscvax This should become: Sender: debbie@kremvax.kgb.comm (Debbie McCormackov) From: sys-op-group: gavrilov@kremvax.kgb.comm (A.I. Gavrilov), smirnov@kremvax.kgb.comm (Z.Z. Smirnov), debbie@kremvax.kgb.comm (Debbie McCormackov); To: edm@burbank.nbc.com, kgbvax!glotz!namei!chongo Cc: brown@nsavax.nsa.gov, gorbie@moscvax.kgb.comm The ``Sender:'' header field was added because the ``From:'' header field did not contain only the user that sent the message. Section 2.2.2: Addresses for mail going to another machine in UUCP. If mail is being sent to a machine that does not require strict conformance to RFC822 (such as allowing !-route notation) then a change may be made to the ``From:'' and ``Sender:'' header fields. If an address in such a header field is in !-route notation, then the name of the current host should be prepended to the current path. This follows a loosely followed standard since more sendmail configuration files seem to do this than otherwise. This interpretation is unpredictably correct. For example, many System V sites without sendmail do not change any header fields. Example: The following header received on the machine ``namei'' that is to be sent to another machine in UUCP: Sender: walldrug!hustead@wall.com From: walldrug!hustead To: namei!amdahl!tron, namei!amdahl!chongo Should be transformed, before being sent, into: Sender: walldrug!hustead@wall.com From: namei!walldrug!hustead To: namei!amdahl!tron, namei!amdahl!chongo Section 2.2.3: Addresses for mail going outside the UUCP domain. For mail going outside the UUCP domain, e.g., to the ARPAnet or some other strictly RFC822-conforming region, all addresses must be fully-qualified in either route-addr form or in user@domain form. Thus, if a ``Sender:'' or ``From:'' field is given in user@sender-domain form, the string ``@sender-domain'' should be added to each !-route or isolated user name. If the sender is only obtainable as a bang-route, then all !-route addresses, or lone user names should be prepended with the route back to the sender and should then be qualified in the domain of the local host. Example: Given the following mail delivered to ``seismo'' that is to be sent to the ARPAnet: From namei!postmast Mon Jan 12 10:12:11 1987 remote from amdahl To: ames!pyramid!csg, amdahl!seismo!prep.ai.mit.edu!rms, Cc: amdahl!sun!ucbvax!fair The transformation should be: From: amdahl!namei!postmast@seismo.css.gov To: amdahl!namei!ames!pyramid!csg@seismo.css.gov, amdahl!namei!amdahl!seismo!prep.ai.mit.edu!rms@seismo.css.gov Cc: amdahl!namei!amdahl!sun!ucbvax!fair@seismo.css.gov Even though this looks like it needs to be improved, this is the only way to guarantee that a !-route is interpreted within the context of the originating host on replies. Section 2.3: Header fields that must exist. There are many non-addressing header fields that must exist and/or may be added. Section 2.3.1: The Received field. For use in tracing/debugging mail, all hosts should add a ``Received:'' field at the beginning of the header. It should identify the host, current date and time, and any unique message ID information. It can also give version numbers for mail transport agents and such. A sample Received: field is: Received: by kray.rsrch.kgb.comm; id <AA01992@localhost.com>; Thu, 1 May 86 12:11:01 1986 See RFC822 for a complete list of standard options that can be added here, though I recommend keeping the Received: fields short. The above information should be adequate for normal tracing/debugging needs. Section 2.3.2: The Message-ID field. Every message should have a reasonably unique message ID. These are for logging purposes. The message ID should be assigned by the host originating a message, though a host is free to assign a message ID to a pass through message if it does not already have one. A reasonable method of making unique IDs is to use the current date, time and an inode number or process ID. Note that your complete domain should be attached to the message-ID, as well. Assuming the use of date, time process ID, the message-ID field might look like: Message-ID: <8711141457-00127@kgbvax.comm> NOTE: This is not a ``<>'' pattern, it is an example. \f