Address used by when doing followups and new posts.

(to-address .  "some@where.com")

This is primarily useful in mail groups that represent closed mailing lists---mailing lists where it's expected that everybody that writes to the mailing list is subscribed to it. Since using this parameter ensures that the mail only goes to the mailing list itself, it means that members won't receive two copies of your followups.

Using to-address will actually work whether the group is foreign or not. Let's say there's a group on the server that is called `fa.4ad-l'. This is a real newsgroup, but the server has gotten the articles from a mail-to-news gateway. Posting directly to this group is therefore impossible---you have to send mail to the mailing list address instead.

Address used when doing a a in that group.

(to-list . "some@where.com")

It is totally ignored when doing a followup---except that if it is present in a news group, you'll get mail group semantics when doing f.

If you do an a command in a mail group and you have neither a to-list group parameter nor a to-address group parameter, then a to-list group parameter will be added automatically upon sending the message if gnus-add-to-list is set to t.

If you do an a command in a mail group and you don't have a to-list group parameter, one will be added automatically upon sending the message.

If the group parameter list has the element (visible . t), that group will always be visible in the Group buffer, regardless of whether it has any unread articles.

Elements like (broken-reply-to . t) signals that Reply-To headers in this group are to be ignored. This can be useful if you're reading a mailing list group where the listserv has inserted Reply-To headers that point back to the listserv itself. This is broken behavior. So there!

Elements like (to-group . "some.group.name") means that all posts in that group will be sent to some.group.name.

If you have (newsgroup . t) in the group parameter list, Gnus will treat all responses as if they were responses to news articles. This can be useful if you have a mail group that's really a mirror of a news group.

If (gcc-self . t) is present in the group parameter list, newly composed messages will be Gcc'd to the current group. If (gcc-self . none) is present, no Gcc: header will be generated, if (gcc-self . "string") is present, this string will be inserted literally as a gcc header. This parameter takes precedence over any default Gcc rules as described later (see Archived Messages).

If the group parameter has an element that looks like (auto-expire . t), all articles read will be marked as expirable. For an alternative approach, see Expiring Mail.

If the group parameter has an element that looks like (total-expire . t), all read articles will be put through the expiry process, even if they are not marked as expirable. Use with caution. Unread, ticked and dormant articles are not eligible for expiry.

If the group parameter has an element that looks like (expiry-wait . 10), this value will override any nnmail-expiry-wait and nnmail-expiry-wait-function when expiring expirable messages. The value can either be a number of days (not necessarily an integer) or the symbols never or immediate.

Elements that look like (score-file . "file") will make `file' into the current score file for the group in question. All interactive score entries will be put into this file.

Elements that look like (adapt-file . "file") will make `file' into the current adaptive file for the group in question. All adaptive score entries will be put into this file.

When unsubscribing from a mailing list you should never send the unsubscription notice to the mailing list itself. Instead, you'd send messages to the administrative address. This parameter allows you to put the admin address somewhere convenient.

Elements that look like (display . MODE) say which articles to display on entering the group. Valid values are:

Elements that look like (comment . "This is a comment") are arbitrary comments on the group. They are currently ignored by Gnus, but provide a place for you to store information on particular groups.

You can use the group parameters to set variables local to the group you are entering. If you want to turn threading off in `news.answers', you could put (gnus-show-threads nil) in the group parameters of that group. gnus-show-threads will be made into a local variable in the summary buffer you enter, and the form nil will be evaled there.

This can also be used as a group-specific hook function, if you'd like. If you want to hear a beep when you enter a group, you could put something like (dummy-variable (ding)) in the parameters of that group. dummy-variable will be set to the result of the (ding) form, but who cares?