Send= Public[,Confirm][,Non-Member]

Send= Private[,Confirm]

Send= Editor[,Hold][,Confirm[,Non-Member | All]][,Semi-Moderated][,NoMIME]

Send= other-access-level[,Confirm]


(Note:  The "Non-Member" and "All" options are available only with "Send= Public,Confirm" or "Send= Editor,Confirm...".  Please see below for full details.)

Defines the categories of users who can mail or send files to the list. Possibly puts the list under control of an editor. 

IMPORTANT:  The default value is "Send= Public".  When creating a new list, you MUST set the Send= keyword explicitly, otherwise the list will allow anyone and everyone to post to it without any restriction.

In the LISTSERV web interface, leaving the Send= keyword unset in the List Configuration page (that is, "---" in the drop-down text box) is the same as setting it to Send= Public, since by leaving it unset, you have accepted the default value.

(However, see also Default-Options=, which allows you to set options such as "REVIEW" and "NOPOST" automatically for new subscribers.  Any options set with the Default-Options= keyword also apply to non-subscribers.  Thus it is possible to have Send= Public and not leave posting wide open if you also have Default-Options= REVIEW or Default-Options= NOPOST.  This being said, we do NOT recommend leaving Send= unset even if using Default-Options= to control posting.)

Other access-levels for use with Send= would include "Private", "Editor", "Owner", etc. (see the beginning of this document for the definition of an access-level). A literal Internet e-mail address may also be used in place of the access-level, for example, Send=joe@foo.bar.com. Using a literal address is one way to ensure that only an authorized person can post to the list, for instance, if the list is an "announce-only" list rather than a discussion list.

Matrix of Allowed Parameter Combinations for the Send= list header keyword

Send=

Public





Public

,Confirm




Public

,Confirm

,Non-Member



Private





Private

,Confirm




Editor





Editor

,Hold




Editor

,Confirm




Editor

,Confirm

,Non-Member



Editor

,Hold

,Confirm



Editor

,Hold

,Confirm

,Non-Member


Editor

,Hold

,Confirm

,All


Editor

,Semi-Moderated




Editor

,Hold

,Semi-Moderated



Editor

,Hold

,Confirm

,Semi-Moderated


access-level

,Confirm




net-address

,Confirm




Requiring confirmation: When the "Confirm" option is enabled, the sender is required to confirm the posting. When LISTSERV receives mail for the list, it sends an e-mail to the sender requesting a confirmation. The confirmation can be accomplished by replying to the confirmation with another e-mail containing the text "OK" (the subject of the confirmation e-mail contains a validation "cookie") or by clicking on the confirmation URL provided in the e-mail. 

List owners can require that non-subscribers actively confirm their messages to the list, while allowing subscribers to post without confirmation. This can dramatically cut down on spam for lists accepting postings from non-subscribers. When "Send=Public,Confirm" is used, the "Non-Member" setting can be specified to limit the confirmation requirements to non-members. When "Send=Editor,Confirm" is used, the "Non-Member" setting can be specified to limit the confirmations to non-members and to require editors to confirm their own posts (see below). 

Moderated/Edited lists: When the list is controlled by an editor (Send= Editor), any file or piece of mail sent to the list is forwarded to the editor, who is the only person (with the list owner) to be able to actually mail or send files to the list. The network address of the editor is defined by the "Editor=" keyword (see below under "List Maintenance and Moderation").

When the "Hold" option is enabled (Send= Editor,Hold), the moderator(s) may approve postings using the "OK" mechanism rather than forwarding the posts back to the list. "Hold" is valid only with "Editor".

When the "Confirm" option is enabled on a moderated list (for instance,  Send=Editor,Confirm), mail sent by any editor or moderator requires confirmation by that editor or moderator. This is to prevent a user from forging mail to the list under an editor's or moderator's return address. The confirmation request is validated with the "OK" mechanism. Please note that this does not mean that a double validation is required when an editor approves other peoples' postings, but only that the editor's own postings to the list and any reposts he does on others' behalf require a confirmation from him that he actually submitted them. In other words if the editor simply "OK"s a posting, he doesn't have to "OK" his own "OK".

It is also possible to set a list to 

* Send= Editor,Hold,Confirm

This allows you to "OK" both subscriber submissions and editor/moderator approvals, as described above.

"Non-Member" and "All" options with "Confirm" (14.3 and later): List owners can require that non-subscribers actively confirm their messages to the list, while allowing subscribers to post without confirmation. This can dramatically cut down on spam for lists that accept postings from non-subscribers. To activate this feature, you would set:

* Send= Public,Confirm,Non-Member

or either

* Send= Editor,Confirm,Non-Member

or 

* Send= Editor,Hold,Confirm,Non-Member

in the list header. 

Documented Restriction:  By definition, only subscribers are allowed to post to a list coded "Send= Private".  Although the LISTSERV error-checking parser will accept “Send= Private,Confirm,Non-Member” when the header is stored, the ",Confirm,Non-Member" part is ignored when incoming messages are processed, and the setting is equivalent to “Send= Private ”, that is, only subscribers will be allowed to post and they will NOT be required to confirm their postings.

The intent of the "Confirm,Non-Member" option is to help list owners cut down spam on public discussion lists, without inconveniencing normal list subscribers. For public lists, it works like "Send= Public,Confirm" if you are not a member of the list, otherwise it works as "Send= Public" (no confirmation required from subscribed users). List owners and editors are considered to be members of the list even if they are not subscribed to it, and are thus not subjected to the confirmation requirement.

For edited lists, the behavior is similar -- non-members must confirm their own postings before they are submitted to the editor for approval, whereas members' postings go directly to the editor for approval without the intermediary step.  It should be noted that ",Confirm" still activates the anti-spoofing feature that already existed, which requires that the editor must approve his own postings.

Please note carefully:  On an edited list, if it is desired for all posters to confirm their own postings regardless of their subscription status, substitute "All" for "Non-Member", that is

* Send= Editor,Hold,Confirm,All

forces all posters to validate their own postings before they are submitted to the editor for final approval.

IMPORTANT: "Non-Member" or "All" must always be specified in conjunction with "Confirm".  For instance, setting "Send= Public,Non-Member" or "Send= Editor,All" will not activate the feature.

Semi-Moderated option for Send= Editor: When the "Semi-Moderated" option is enabled (Send= Editor,Semi-Moderated), mail sent to the list will be treated in one of two different ways, depending on the contents of its "Subject:" field.  If the subject starts with "Urgent:" (case-independent), the list is treated as a non-moderated one, which means that the message will be immediately distributed provided that the sender matches the access-level description.  If the subject does not start with "Urgent:", the message is forwarded to the primary list editor (unless it came from someone defined as an editor).  A "Subject:" field beginning with "Re: Urgent:" is treated identically, so that replies to urgent messages are by default considered urgent.

Documented Restriction:  In order to be able to override moderation, the sender must be subscribed to the list.  This prevents the unintended distribution of random spam with "Urgent:" in the subject line.  Note that such messages sent by non-subscribers will be rejected rather than forwarded to the moderator.

Note that 

* Send= Public,Semi-Moderated

and

* Send= Private,Semi-Moderated

are unavailable and ",Semi-Moderated" will be ignored.  In both cases, no Editor is involved, therefore either anyone ("Public") or any list subscriber ("Private") may post without moderation.

A correct usage example:

* Send= Editor,Semi-Moderated

* Editor=NATHAN@EXAMPLE.COM,ERIC@EXAMPLE.COM

In this example, a message sent to the list would be:

      • Processed, if the sender used the "Urgent:" subject
      • Forwarded to the moderator if the sender didn’t use the "Urgent:" subject.

Note that in the above example, messages don’t get discarded if the sender isn’t subscribed.

Moderation "OK" requests and MIME attachment display:  When moderating MIME messages which may have multiple encoded parts, LISTSERV includes a copy of the first text/plain part (if one exists in the message) in the moderation request message for the purpose of quick screening.  The following restrictions apply:

1. This is only done for MIME messages (even simple single-part ones, but they must have MIME headers). 

2. The text part in question is sent pretty much 'as is', that is, as an extra text/plain part in the message, with all the options and encoding and what not supplied in the original message. The reason is quite simply that it would be a lot of work and, in some extreme cases (incompatible code page, etc), completely impossible, to embed it into the first text/plain part with the LISTSERV message. The drawback is that some mail agents might conceivably only show the first part until you take some kind of clicking action. 

It is important to understand that only the first text/plain part is extracted in this fashion. The goal was to make it easier to approve or reject simple text messages, not to build a factory around a simple problem. The ENTIRE message is available at an extra click. 

Where security is a concern, it is important to review the ENTIRE original message and not just the plain text part. There could be an obscene GIF or another text part or a text/html part not matching the contents of the text/plain part or whatever. This is why, again, you are given the ENTIRE original message.

If preferred, LISTSERV can send the "raw" message in the moderation request message without any decoding.  This is done by specifying "NOMIME" in the Send= list header keyword; for instance,

* Send= Editor,Hold,NoMIME

"Hold" forced for multi-part moderated messages:  LISTSERV will force ",Hold" if it is not specified with "Send= Editor" for multi-part messages, in order to generate an approval request that can display the multi-part message correctly.