Message Headers (Message Manual)

Next: Mail Headers, Up: Variables [Contents][Index]

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).