>Hello,
>
>This has to do with the fact that when a message goes through to a list the
>original destination information is obliterated from the TO and CC lines.
>As I explain if I send a message:
>
>TO: [log in to unmask]
>cc: [log in to unmask]
>
>When the message comes through the LSoft list there is NO READILY VISIBLE
>CLUE that the message was also sent to JOE. The context of the message may
>DEPEND on that information being visible.
>
>Most redistribution lists attempt to preserve the original TO/CC header
>information as much as possible. Listserv lists strip it out completely,
>and replaces ALL of the original destination info with a simple:
>
>TO: [log in to unmask]
This is incorrect. Depending on the mailing list settings a
Comments: or X-To line will contain the "missing" information.
>This destroys the context of the original addressees.
>
>Why ?
It is usually problematic having someone not subscribed to a mailing
list participating in mailing list discussions. For instance if they
no longer are interested in the discussion there will be no easy way
for them to "unsubscribe" from it, particularly if the mailing list
is Send= Private.
There are cases where these kinds of concerns are not an issue, but
there are also many cases where they are.
>and is there something we can do to prevent this.
If a subscriber is set to IETFHDR then he or she will receive mailing
list messages with relatively unaltered headers. This has some
side-effects which will be discussed below, but you may find it
useful.
To set everyone to IETFHDR, set
Default-Options= IETFHDR
in your mailing list's settings and issue a
QUIET SET listname IETFHDR FOR *@*
command. Note the following:
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).
o Also, see the warnings in the release notes for 1.7f, 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 <<<<<<<<<<<<<<<<<<<<<<<
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--
Jacob Haller, Technical Support
L-Soft international, Inc
http://www.lsoft.com/
|
