At 10:05 AM 2/23/2004 -0500, Nick Abiola-Bisiolu wrote:
>Hi,
>
>When a message is sent to a list and other email addresses were copied in
>the message. The "CC" field comes back blank when the mailing list
>distributes the message. The the message header in the property displays the
>X-To and X-CC.
>How can the same information be displayed in the actual message. Users are
>not willing to search message property to identy who was copied in a mail
>message to a list.
Nick, first, please don't crosspost both to [log in to unmask] and to
LSTSRV-L. Most of our support techs monitor LSTSRV-L so there is no need
to post both places. This being said:
It is often problematic to include a non-list member in an ongoing
discussion on a mailing list, as they have no effective way to stop
receiving it and may not even be allowed to post to the mailing list
itself. It is for reasons like this that LISTSERV modifies the To: and Cc:
headers.
If this isn't the desired behavior, then you have the option of using
IETFHDR. This does have some side effects however:
o With IETFHDR, the mail headers cannot be changed in any way by LISTSERV.
If someone sends mail to [log in to unmask], that capitalization
is exactly what people on the receiving end will see if their subscription
is set to IETFHDR. This _may_ cause problems with mail filters.
o If you have Reply-To= coded in your list header, that will not be
respected for subscriptions set to IETFHDR.
o You cannot have the subject-tag added to the Subject line (SUBJECTHDR)
(again, this may break some people's mail filters if you change their
subscription options without warning).
o You cannot have the DUALHDR option, which some mail clients require
(CC:mail comes to mind). It should be noted that setting IETFHDR also
nullifies FULLHDR, FULL822, and all other header-formatting settings
available to the subscriber. You can only have one of these set at a time.
o Also, see the warnings in the release notes for 1.7f (appended below),
when IETFHDR was first introduced. The most important one is that if
someone sends a message with syntactically incorrect mail headers, that is
_exactly_ how LISTSERV will send it, and it may mean that the message is
unreadable to some of the recipients.
> **************************************
> * Usability: IETF-style mail headers *
> **************************************
>
> WARNING: There are a number of important warnings in this section. Read
> them carefully. In particular, IETF-style headers must NOT be used by
> LISTSERV-to-usenet gateways.
>
> DISCLAIMER: All references to the discussions of the IETF "listserv
> working group" reflect the author's personal appraisal of the debate on
> the working group's list, as of late august 1991 (shortly before the code
> being described was written). At this time, the group did not expect to
> produce a RFC (other than a possible informational one) in the immediate
> future, and the first non-informational RFC was not expected to address
> the topic of mail headers. This topic has, however, been thoroughly
> debated on the list, and it is this debate that the author's comments are
> based upon. The working group archives are available via anonymous FTP
> from FTP.UTDALLAS.EDU, should you want to form you own opinion on the
> matters at hand.
>
> Up to and including version 1.7a, LISTSERV provided two flavours of
> RFC822 headers: SHORT, with just the "essential" fields, and FULL, with
> all fields (including those usually deemed "superfluous", such as
> 'Received:'). For both types of header, two delivery mechanisms were
> supported: "regular" delivery, with the recipient's address listed in the
> RFC822 'To:' field, and "BSMTP" delivery, with a generic 'To:' field not
> pointing to the recipient. This resulted in four possible header options:
> SHORTHDR, SHORTBSMTP, FULLHDR and FULLBSMTP. The only difference between
> the HDR and BSMTP options is the contents of the 'To:' field, which for
> the present discussion is immaterial: we only need to consider the SHORT
> vs FULL attribute of the header.
>
> Due to their different culture and habits, Internet people are usually
> not satisfied with either option. Most Internet users (or at least most
> of the vocal ones) read mail from workstations and use sophisticated user
> interfaces which hide "uninteresting" header fields automatically; they
> are thus not interested in any removal of "superfluous" tags at the
> sending point (and contend that the bandwidth saved is immaterial, given
> T1-speed access). They are furthermore used to SMTP alias lists, which
> are basically a feature of Internet mail systems making it possible to
> have the mailer replace a given mailbox with a list of mailboxes on the
> fly; in other words, by sending mail to [log in to unmask] your message is
> automatically sent to a number of people as it reaches the host Y.EDU, by
> causing the mail system to internally expand the recipients list without
> touching anything else. In particular, the mail header is unaltered and
> still reads 'To: [log in to unmask] - the 'To:' field is where you should look for
> the list name. The IETF's "standard listserv" RFC's will be based on this
> type of headers, and disallow the LISTSERV-style ones.
>
> In order to allow BITNET users to become familiar with Internet-style
> headers and to decrease the rate of incoming "suggestions" for future
> development of LISTSERV from Internet users forced to subscribe to
> BITNET-based mailing lists for professional reasons, a third type of mail
> header is being introduced: 'IETFHDR' (which always uses BSMTP delivery).
> That is, one would send a 'SET XYZ-L IETFHDR' command to LISTSERV to
> switch to IETF-style headers.
>
> For a regular, non-peered list, the IETFHDR is the header LISTSERV
> received from the mail system with exactly three changes:
>
> 1. A 'Received:' line is added on top of the header.
>
> 2. A 'Message-ID:' field is added, if none was present in the incoming
> message.
>
> 3. The 'Sender:' tag is set to the value of the "Sender=" list header
> keyword, if one is supplied, or to 'OWNER-listname@hostname' (in lower
> case). For instance, a posting sent to the list [log in to unmask] would
> have a default 'Sender:' tag value of [log in to unmask]
>
> It is important to understand that these headers are not being provided
> in answer to requirements from non-DP-literate users. They are being
> provided to answer requirements from Internet specialists; it is "their"
> headers, not "ours". They are not meant to be user-friendly and are not
> open to negotiations. They will not spawn sub-options with various bells
> and whistles added. They are here to allow LISTSERV to emulate an SMTP
> redistribution list if desired, and nothing more.
>
> Note that this does not mean that LISTSERV will be converted to become
> compliant with the upcoming "IETF listserv" standard, nor that setting a
> list to use IETFHDR for all subscribers will make it IETF-compliant. It
> is the author's opinion that the "IETF listserv" standard will not make
> it possible for LISTSERV to be compliant without becoming totally
> incompatible and ceasing to address the needs of some categories of
> BITNET users. In particular, the very fact of allowing users to request,
> no matter how explicitly, that headers be delivered in a format other
> than IETFHDR would be a violation of the future standard, assuming no
> change in the direction of the working group from what the author
> experienced during his participation. Since the "IETF listserv" is going
> to be a fully-specified standard and one of the goals of the "IETF
> listserv" working group (again, assuming no change of direction) is to
> see to it that it is implemented in a portable way, it seems more
> appropriate to have whatever new software the Internet comes up with
> replace LISTSERV, rather than striving to turn LISTSERV into a poor
> emulation of the latest fashion. Indeed, it would seem unlikely for more
> than a small minority of sites to want to run such a service on an
> expensive mainframe if it can be provided as easily on cheaper hardware.
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>> IMPORTANT WARNINGS regarding the IETFHDR option <<<<<<<<<<<<
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> A. LISTSERV does not alter the header beyond the three points mentioned
> above: insertion of a 'Received:' line, generation of a 'Message-ID:'
> if not already present, and generation of a 'Sender:' field. This
> means LISTSERV cannot guarantee that the header is syntactically or
> semantically correct, beyond the fields it generates itself. Because
> of this, THE IETFHDR OPTION MUST BE NOT USED FOR SUBSCRIBING PROGRAMS
> WHICH REACT ON THE CONTENTS OF THE HEADER. This means you must not use
> this option for a usenet gateway, but you can subscribe a "logger"
> program which just appends everything it receives to a disk file.
>
> B. LISTSERV does not (and cannot) take control of the "owner-listname"
> address, which is normally too long to be a valid VM userid. It is the
> responsibility of the list owner to ensure that an alias for this
> address is set in the mailer at the site hosting the list if he wants
> to receive delivery errors sent to that address.
>
> C. In a peered-list environment, the IETFHDR option will operate properly
> only if ALL peers are running release 1.7b or higher. If this is not
> the case, some postings sent to IETFHDR subscribers may appear with a
> FULLBSMTP-like header; this is not a bug, but a consequence of the
> simple fact that the original header has not been preserved by the
> peer to which the posting was sent.
>
> D. If the posting received by LISTSERV comes in a format other than
> RFC822 (eg PROFS), LISTSERV will generate a new header out of the
> information at hand. Such a header may look "suspiciously short", so
> it was felt necessary to mention this possibility.
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> End of important warnings <<<<<<<<<<<<<<<<<<<<<<<
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Nathan
|