>We have a few lists where we need the ability to have replies directed to
>all addresses included in the original mail (ie, the To:, Cc:, and
>From: addresses). It appears that the best Listserv can do is using
>Reply-to=Both,Ignore which will have replies directed to the list and the
>From: address. Have we missed some way to accomplish this?
>
>If an enhancement to Listserv is required to accomplish this, I suggest
>Reply-to=All,Ignore as a logical syntax.
It sounds like you want the mailing list to basically operate as a
mail alias. For something like that, I generally would use:
Default-Options= IETFHdr
and issue a "quiet set listname ietfhdr for *@*".
IETFHDR does have some side-effects which may make it undesirable for
use with many mailing lists:
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).
IETFHDR was introduced in LISTSERV 1.7f and some additional
information and warnings regarding it can be found in the 1.7f
release notes. These don't appear to be online, so here's the
relevant excerpt:
> **************************************
> * 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/
Support is available 9:00-18:00 ET, Monday-Friday
except on the following holidays:
http://www.lsoft.com/products/default.asp?item=holidays
|
