3.1 Message Headers

Message is quite aggressive on the message generation front. It has to be—it’s a combined news and mail agent. To be able to send combined messages, it has to generate all headers itself (instead of letting the mail/news system do it) to ensure that mail and news copies of messages look sufficiently similar.

message-generate-headers-first

If t, generate all required headers before starting to compose the message. This can also be a list of headers to generate:

(setq message-generate-headers-first
      '(References))

The variables message-required-headers, message-required-mail-headers and message-required-news-headers specify which headers are required.

Note that some headers will be removed and re-generated before posting, because of the variable message-deletable-headers (see below).

message-draft-headers

When running Message from Gnus, the message buffers are associated with a draft group. message-draft-headers says which headers should be generated when a draft is written to the draft group.

message-from-style

Specifies how From headers should look. There are four valid values:

nil

Just the address—‘[email protected]’.

parens

[email protected] (Elvis Parsley)’.

angles

Elvis Parsley <[email protected]>’.

default

Look like angles if that doesn’t require quoting, and parens if it does. If even parens requires quoting, use angles anyway.

message-deletable-headers

Headers in this list that were previously generated by Message will be deleted before posting. Let’s say you post an article. Then you decide to post it again to some other group, you naughty boy, so you jump back to the *post-buf* buffer, edit the Newsgroups line, and ship it off again. By default, this variable makes sure that the old generated Message-ID is deleted, and a new one generated. If this isn’t done, the entire empire would probably crumble, anarchy would prevail, and cats would start walking on two legs and rule the world. Allegedly.

message-default-headers

Header lines to be inserted in outgoing messages before you edit the message, so you can edit or delete their lines. If set to a string, it is directly inserted. If set to a function, it is called and its result is inserted.

message-subject-re-regexp

Responses to messages have subjects that start with ‘Re: ’. This is not an abbreviation of the English word “response”, but it comes from the Latin “res”, and means “in the matter of”. Some illiterate nincompoops have failed to grasp this fact, and have “internationalized” their software to use abominations like ‘Aw: ’ (“antwort”) or ‘Sv: ’ (“svar”) instead, which is meaningless and evil. However, you may have to deal with users that use these evil tools, in which case you may set this variable to a regexp that matches these prefixes. Myself, I just throw away non-compliant mail.

Here’s an example of a value to deal with these headers when responding to a message:

(setq message-subject-re-regexp
      (concat
       "^[ \t]*"
         "\\("
           "\\("
             "[Aa][Nn][Tt][Ww]\\.?\\|"     ; antw
             "[Aa][Ww]\\|"                 ; aw
             "[Ff][Ww][Dd]?\\|"            ; fwd
             "[Oo][Dd][Pp]\\|"             ; odp
             "[Rr][Ee]\\|"                 ; re
             "[Rr][\311\351][Ff]\\.?\\|"   ; ref
             "[Ss][Vv]"                    ; sv
           "\\)"
           "\\(\\[[0-9]*\\]\\)"
           "*:[ \t]*"
         "\\)"
       "*[ \t]*"
       ))
message-subject-trailing-was-query

Controls what to do with trailing ‘(was: <old subject>)’ in subject lines. If nil, leave the subject unchanged. If it is the symbol ask, query the user what to do. In this case, the subject is matched against message-subject-trailing-was-ask-regexp. If message-subject-trailing-was-query is t, always strip the trailing old subject. In this case, message-subject-trailing-was-regexp is used.

message-alternative-emails

Regexp or predicate function matching alternative email addresses. The first address in the To, CC or From headers of the original article matching this variable is used as the From field of outgoing messages, replacing the default From value.

For example, if you have two secondary email addresses [email protected] and [email protected] and want to use them in the From field when composing a reply to a message addressed to one of them, you could set this variable like this:

(setq message-alternative-emails
      (regexp-opt '("[email protected]" "[email protected]")))

This variable has precedence over posting styles and anything that runs off message-setup-hook.

message-allow-no-recipients

Specifies what to do when there are no recipients other than Gcc or FCC. If it is always, the posting is allowed. If it is never, the posting is not allowed. If it is ask (the default), you are prompted.

message-hidden-headers

A regexp, a list of regexps, or a list where the first element is not and the rest are regexps. It says which headers to keep hidden when composing a message.

(setq message-hidden-headers
      '(not "From" "Subject" "To" "CC" "Newsgroups"))

Headers are hidden using narrowing, you can use M-x widen to expose them in the buffer.

message-header-synonyms

A list of lists of header synonyms. E.g., if this list contains a member list with elements CC and To, then message-carefully-insert-headers will not insert a To header when the message is already CCed to the recipient.

message-syntax-checks

Controls what syntax checks should not be performed on outgoing posts. To disable checking of long signatures, for instance, add

(signature . disabled)

to this list.

Valid checks are:

approved

Check whether the article has an Approved header, which is something only moderators should include.

continuation-headers

Check whether there are continuation header lines that don’t begin with whitespace.

control-chars

Check for invalid characters.

empty

Check whether the article is empty.

existing-newsgroups

Check whether the newsgroups mentioned in the Newsgroups and Followup-To headers exist.

from

Check whether the From header seems nice.

illegible-text

Check whether there is any non-printable character in the body.

invisible-text

Check whether there is any invisible text in the buffer.

long-header-lines

Check for too long header lines.

long-lines

Check for too long lines in the body.

message-id

Check whether the Message-ID looks syntactically ok.

multiple-headers

Check for the existence of multiple equal headers.

new-text

Check whether there is any new text in the messages.

newsgroups

Check whether the Newsgroups header exists and is not empty.

quoting-style

Check whether text follows last quoted portion.

repeated-newsgroups

Check whether the Newsgroups and Followup-To headers contains repeated group names.

reply-to

Check whether the Reply-To header looks ok.

sender

Insert a new Sender header if the From header looks odd.

sendsys

Check for the existence of version and sendsys commands.

shoot

Check whether the domain part of the Message-ID header looks ok.

shorten-followup-to

Check whether to add a Followup-To header to shorten the number of groups to post to.

signature

Check the length of the signature.

size

Check for excessive size.

subject

Check whether the Subject header exists and is not empty.

subject-cmsg

Check the subject for commands.

valid-newsgroups

Check whether the Newsgroups and Followup-To headers are valid syntactically.

All these conditions are checked by default, except for sender for which the check is disabled by default if message-insert-canlock is non-nil (see Canceling News).