Headers in Pine

Help for Pine - Headers

You are in Home > Miscellaneous > Headers

Index

Setting Headers when Composing a Message
Setting Headers when Reading a Message
C-Client Headers

Introduction

Headers in an e-mail message serve the same purpose that the words written on the outside of an envelope in a letter that you receive in the mail. They tell you about the sender, they tell you about the route that the message took to get to you, and they may even contain advertisement!.

In this section we will see the two sides of header configurations in Pine, how to configure those that you want to see when reading a message, and configuring those that you want to be read by the addressee of your message.

Setting Headers when Composing a Message

Pine lets you set most of your headers in any way you want, there are a few which are the exception, which we will talk about here. First let us see the default headers in Pine, what they mean, and how to use them.

Default Composer Headers

The default composer headers are To, Cc, Attchmnt and Subject. Let us see what they mean.

To: The To: header is used to enter the e-mail address of the person(s) that you are addressing the message to. It is understood that you will write here the address of the main adressee of this message, and you should probably try to write the address of only one person here. If you need to write more than one e-mail address you should consider using the Cc, Bcc or Lcc fields.

If you do not want to enter a full address, because it's too long, you may consider to add the address of this person to the addressbook, and entering a nickname instead of an e-mail address, which is usually a very convenient way to.

You can also enter the name of the person. This is usually nicer because it gives a more human touch to an e-mail, than what an e-mail address can give. Here are the rules that you must follow if you add this manually.
1. Enclose the e-mail address between < and >, so something like <peter@bedrock.com> is a valid way to write the e-mail address.
2. Put the e-mail address at the end of the line, in the beginning you should write the name of the person, so something like Peter Flinstones <peter@bedrock.com> should work. If you are only going to enter the e-mail address (and not the name), you do not need to enclose the address between < and >.
3. You can't write more than one space at any time in this field.
4. If you need to write more than one address, separate all entries by a comma ",".
5. You can get the same effect as before if you do not write the e-mail address between < and > and write the personal name following it, but enclosed in parenthesis. Therefore, writing peter@bedrock.com (Peter Flinstones) is equivalent to writing Peter Flinstones <peter@bedrock.com>.
  
  Notice, however, that if you enclose the address between < and >, then all text enclosed in parenthesis will be ignored, so <peter@bedrock.com> (Peter Flinstones) is equivalent to writing peter@bedrock.com.
  
  Note also that if you do not enclose the text in parenthesis, Pine will complain asking you to enter a comma to separate addresses.
Cc: The Cc: header is used to send copies of the message addressed to the person in the To: field, to another recipient. The format for entering an address here is the same as for the To field, which was described above.
Attchmnt: Yes, only one vowel. This is due to the fact that no matter what the name of the header is, Pine will only write the first 8 characters of its name. In this case, almost all vowels have been removed. In any case, Attchmnt is an abreviation for Attachment. If the vowels had not been removed, and we follow the above rule it would have looked as Attach Me, with the obvious confusion that this may lead to, as to what this means.

Attachment, in this context, is just another word for "file", and the idea here is that you must enter the name of the file that you want to send to the receivers of your message. In general, you should enter the full path to the file. For purposes of demonstration I will show you how to attach your ".pinerc" file.
1. Go into the Attchmnt field and write ~/.pinerc. Notice that this gives the full path, since "~" is an abbreviation for the home directory of the user.
2. After you've entered this text and pressed the RETURN key, you will see that the above text changes to something like
```
1. /h3/chappa/.pinerc (36 KB) ""
```
  The first number is the "Attachment Number", attachments are numbered sequentially. You can't edit this number. The next text is the location of the file in your computer system. This should give you a hint about if you are attaching the correct file. This is followed by the size of the attachment. You should not use e-mail to send large attachments. As a rule never send anything bigger than 500 KB. Most sites forbid you to send attachemnts that are bigger than 2 MB in size. Finally there are two quotation marks. You should always use these to indicate the sender, what this file is, so that they do not have problems seeing what you sent them. In this case, I will add the comment "my pinerc file", which will be seen by the receiver. The comment must be written between the quotes:
```
1. /h3/chappa/.pinerc (36 KB) "my pinerc file"
```
  Now, it's time to notice an important, but many times overlooked part in this process. At the bottom of the screen, you will see a message which looks as follows:
```
[File /h3/chappa/.pinerc attached as type TEXT/PLAIN]
```
  The key part of this message is that it says "type TEXT/PLAIN". It is always important that whatever it says there must correspond to what the file contains. In other words, a TEXT/PLAIN file is not an image. Images, should have a type like IMAGE/GIF or IMAGE/JPEG, etc. This is important because there is a mechanism which can be used, to help Pine determine how to open an attachment if its type is known. You can read how to do this by following this link.
If you need to add another attachment, only add a comma "," at the end of the last attachment and repeat the above process, for example if I wanted to attach my file ".pine-debug2" file together with my ".pinerc" file, I would write
```
1. /h3/chappa/.pinerc (36 KB) "my pinerc file", ~/.pine-debug2
```
and after I press RETURN, it will look like:
```
 1. /h3/chappa/.pinerc (36 KB) "my pinerc file",
 2. /h3/chappa/.pine-debug2 (208 KB) ""
```
which I can add another comment to indicate to the receiver that this is the debug file.

Now that we have seen how to attach a file, let us see a few tips.
1. If you don't know the full path to the file that you want to attach, you can try to find it if you press ^T, when you put the cursor over this field. This is a nice way to find any file.
2. You can also attach any file by pressing ^J in the headers section, at any time. You will be asked by the name of the file (and can use ^T to find it, if necessary), and after that you will be asked for a comment, as pointed out before.
Finally, if you decide not to send a specific attachment, you must delete the full line that contains the name of the attachment, and this is done by pressing the ^K key when the cursor in on the line that contains the attachment that you do not want to send. Do not use the "Backspace" or "Delete" key to do this, since at the end you will get to the "Attachment Number", which as we said before can not be edited (but only deleted).
Subject: This field is used to indicate the addressee what the message is about. It is not necessary to fill this field, but it's a good practice to do so. The standard indicates that a reply to a message must have it's subject beginning with the string Re: .

Hidden Default Composer Headers

There are a number of headers that do not need to be configured in any way, which you can edit, but do not appear in the screen, when you first start composing a message. In order to edit the value of these headers, you must put the cursor in the headers section of the editor and press ^R. Notice that pressing ^R once again will revert you to the state of the headers before you pressed ^R. The following gives you a list of the hidden default composer headers: Bcc:, Lcc:, Newsgrps: and Fcc:.

Below you can read the meaning and use of these headers.

Bcc: Normally, when you send a message the Mail User Agent (MUA) that the addressee is using, shows the list of recipients of the message. This includes the addresses entered in the To: and Cc: fields. If you wish to send the message to a person and you do not want that recipient to be listed in the list of recipients, you must enter his/her e-mail address in this field, in the same way that you enter an e-mail address in the To: or Cc: fields.

In particular, this header could be used to send a single message to several recipients, without indicating any particular person in the To: field. When Pine sends a message without any person being listed in the To: field, Pine will create a fake addressee in the To: field. The text that will appear in the To: field is controlled by the configuration option empty-header-message, whose default value is set to Undisclosed Recipients, and this is what the recipients of your message will see in the To: field when they read it. Actually, to be precise, they will see the following text: To: Undisclosed Recipients: ;.

Notice that the value Whatever Text Here: ; is also a value for the To: field. The text "Undisclosed Recipients: ;" is generated automatically by Pine, but you could also write this text, if you so wished directly. This has an interesting application as we will see later.
Lcc: The Lcc: field, is very similar to the Bcc: field, in the sense that any e-mail address entered here will not be seen by the recipients of the message. The main difference is that the To: field will be filled with the personal name of the recipient (if known). The main application of this field is the following. Say that you are in charge of sending messages to a group of people, and you create a nick in your addressbook to put all the people in one list (that's where the L in Lcc: comes from), then when entering the nick for this list in this field, the To: field will be filled with the name of the list (which is usually what you wrote under Fullname when you created a nick for the list.

An interesting application of this field, is the following. It is usual that networks create distribution lists (e.g. all@domain.com), which are used to spread news of general interest to everyone, say. If you enter the address all@domain.com in the Bcc: or Lcc: field, that would prevent that people replying to your message will send copies of their messages to everyone. If you want to avoid generating traffic because somebody is replying to your message, use this field, and write something meaningful in the To: field. Something like "all@domain.com: ;" is good enough to let everyone know who you sent the message to.
Newsgrps: In this field you should write the name of the newsgroup that you want your message to be posted in. This may be in addition, to any e-mail address that you may want to use to send this message to (which means that the message may be e-mailed and posted at the same time). Pine will use the first server in your list of nntp-servers that it can connect to, in order to post your message.

Notice that this does not guarantee that your message will be posted, because you may be trying to post to a newsgroup that is not carried by the server that you are trying to use, so you should have your list of news-servers arranged in a way that this kind of errors won't happen.

There is no way to specify a nntp-server when composing a message, nor a smtp-server. This is a long awaited feature in Pine. The only workaround exisitng today is to use this patch.
Fcc: Here you specify which folder you want to use to keep a copy of the message that you are sending. The default name of this folder is defined in the file pine/osdep/os-xxx.h, its the value of the constant DF_DEFAULT_FCC.

The folder may be remote and its path is specified in the form {name.server.com/user=yourid}/full/path/to/fcc/folder.

Notice that messages saved in this folder, when used this way, contain an empty Status header, which makes them look as if they were new messages, which is very annoying for some people, since these messages were already read (and written!) by you. However, they can be marked as seen if you enable the option mark-fcc-seen.

This folder can be a hidden folder in your mail/ collection, even if you have not enabled enable-dot-folders. Observe that this is a sneaky way to define a fcc folder as this folder is not listed if the above configuration option is not on, but it can be used to save messages, nevertheless.

Configuring other Headers

If you want to configure the value of a header that does not appear in the above list, you will need to edit your configuration file. The way to do this is by going to the configuration screen and adding the following text to the customized-hdrs option:

customized-hdrs = Header_name: Value

The Value part above is not required, nor is the colon after the Header_name. Here are some examples of possible additions you may want to consider

customized-hdrs = From: "Your Name" <email@address.com>,
                  Reply-To: "Your Name" <another@address.org>,
                  Control:,
                  Status:,
                  X-Status:

Note that changing the From field can be disabled during compilation, and it is done by adding the following line to the file pine.h:

#define NEVER_ALLOW_CHANGING_FROM

Also note that any header that you add in the customized-hdrs variable is not visible when you start to compose a message. The are two ways to make it visible. You can either go into the headers section of the message that you are composing and press ^R to make it visible (which will make all headers visible), or you can add the same header to the default-composer-headers variable. Note that if you leave this variable empty then only a few headers (To:, Cc:, Attchmnt: and Subject:) will be visible by default and adding a value here overrides the default, making the added values here the default. In particular if you are thinking of adding any field here at all, you will probably want to add more than one field at least!.

Note that there are some headers that you can not edit, nor you should add to the list of customized-hdrs. The list of headers that can not be edited within Pine is the following: Message-Id, In-Reply-To, References, Date, Sender, X-Sender, X-X-Sender, Received, Path, Resent-Message-Id, Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Reply-To, Mime-Version, Content-Type X-Post-Error, X-Reply-Uid, X-Our-Reply-To and X-Cursor-Pos. Below is a table showing a quick explanation of what information contain these headers.

Header Name Description

Message-Id Contains a string which uniquely identifies the message in the internet. In Pine this field is formed as follows: PINE.SYSTEM.YEAR MONTH DAY TIME_BEGIN 0.PROCESS_NUMBER-100000@localdomain, where SYSTEM is a code for the system that you are using (WNT, CYG, LNX, etc), and YEAR, MONTH, DATE, TIME_BEGIN represent the date when you started composing this message (so that big brother can know how long you spent in e-mail), then comes the process number in your system, and finally the name of the machine that you were using to write this message.

In-Reply-To Contains the Message-Id of the message that is being replied to. If the message is not a reply to another message, this header is not present.

References This header is formed by appending the value of the In-Reply-To header of the message being replied to. In versions previous to 4.50, Pine only kept this header when you posted a message. In fact, when you sent e-mail this header was dropped. Finally, developers saw the light and now this header is not dropped ever!.

Date This header contains the date that the message was sent. You can not change the value of this header. Its value is obtained from the local machine that you are using to run Pine (if you are in Seattle, and your server was in London, the time would be Seattle's time). It includes the Time zone.

Sender
X-Sender
X-X-Sender The Sender header contains the mailbox of the person that sent the message. It differs from the From field in that the From field may contain an invalid mailbox. The Sender field always contains the correct information about who sent the message. It is normally generated when the From field differs from the information that the Sender field would contain if it had to be generated. By default Pine calls this header X-X-Sender, but if you enable the option [X] use-sender-not-x-sender, then Pine will use the Sender header instead. Starting in Pine4.51, you can have Pine not generate this header if you enable the option [X] disable-sender.

Received The Received: header contains a log of the route that the message took to get to you. It is read, in cronological order, from bottom to top. This means that the last server that it passed through, to get to you, is at the top, while the first one is at the bottom. This header is important when you want to know who sent the spam that you received, as it allows you to trace it back, to its origin.

Path This is the equivalent of the Received header, but it is used for tracing all the servers that a message had to pass in order for you to be able to read it as a USENET post. Again, the last server it passed through is at the beginning of the line, and normally its last field is the name of the person sending the message.

Resent-Message-Id A Resent type header is generated when you bounce a message. In this case, Pine generates a new Message-Id, which does not replace the Message-Id of the original message, but identifies Pine as the agent "bouncing" the message.

Resent-Date This is the date when the message was bounced.

Resent-From This is the address and personal name of the person that bounced the message to you. You can not edit the contents of this header, as you can with the From field.

Resent-To This is the personal name and e-mail address of the person you are bouncing a message to.

Resent-Cc The Cc field of the original message that was bounced.

Resent-Reply-To The Reply-To field of the person bouncing the message.

Mime-Version This is a string of the form "X.Y", indicating the version, which indicates the RFC number which Pine is following. In this case it refers to RFC 1521.

Content-Type This is normally used to indicate how the message is structured. For example if the message contains attachemts, then this is set to "multipart", but if it's only text, it could be "text/plain" or "text/html", etc.

X-Post-Error This header is generated if there was an error to post the message, and is saved in a message in the postponed-msgs folder. The contents of this field are displayed when you continue the message.

X-Reply-Uid Internal header designated to contain information about a message. It is only found in messages in your postponed-msgs folder and its presence indicates that the message being postponed is a reply to another message. It's value is composed of three fields that are structured as follows:
(Field1)(Field2)Field3
. The value of Field1 indicates the indent-string used to reply, and its length. Field3 contains the mailbox that the message being replied to was found and Field2 contains information on the location of the message being replied to in that mailbox.

X-Our-Reply-To It indicates if there is a Reply-To header or not, by having values Full or Empty. Full indicates that Reply-To exists and is filled, and empty that this header does not exist.

X-Cursor-Pos This header indicates where the cursor was located when the message was postponed. The number represented here indicates how many characters must Pine advance from the beginning of the message to reach its last known position.

Header Name	Description
Message-Id	Contains a string which uniquely identifies the message in the internet. In Pine this field is formed as follows: PINE.SYSTEM.YEAR MONTH DAY TIME_BEGIN 0.PROCESS_NUMBER-100000@localdomain, where SYSTEM is a code for the system that you are using (WNT, CYG, LNX, etc), and YEAR, MONTH, DATE, TIME_BEGIN represent the date when you started composing this message (so that big brother can know how long you spent in e-mail), then comes the process number in your system, and finally the name of the machine that you were using to write this message.
In-Reply-To	Contains the Message-Id of the message that is being replied to. If the message is not a reply to another message, this header is not present.
References	This header is formed by appending the value of the In-Reply-To header of the message being replied to. In versions previous to 4.50, Pine only kept this header when you posted a message. In fact, when you sent e-mail this header was dropped. Finally, developers saw the light and now this header is not dropped ever!.
Date	This header contains the date that the message was sent. You can not change the value of this header. Its value is obtained from the local machine that you are using to run Pine (if you are in Seattle, and your server was in London, the time would be Seattle's time). It includes the Time zone.
Sender X-Sender X-X-Sender	The Sender header contains the mailbox of the person that sent the message. It differs from the From field in that the From field may contain an invalid mailbox. The Sender field always contains the correct information about who sent the message. It is normally generated when the From field differs from the information that the Sender field would contain if it had to be generated. By default Pine calls this header X-X-Sender, but if you enable the option [X] use-sender-not-x-sender, then Pine will use the Sender header instead. Starting in Pine4.51, you can have Pine not generate this header if you enable the option [X] disable-sender.
Received	The Received: header contains a log of the route that the message took to get to you. It is read, in cronological order, from bottom to top. This means that the last server that it passed through, to get to you, is at the top, while the first one is at the bottom. This header is important when you want to know who sent the spam that you received, as it allows you to trace it back, to its origin.
Path	This is the equivalent of the Received header, but it is used for tracing all the servers that a message had to pass in order for you to be able to read it as a USENET post. Again, the last server it passed through is at the beginning of the line, and normally its last field is the name of the person sending the message.
Resent-Message-Id	A Resent type header is generated when you bounce a message. In this case, Pine generates a new Message-Id, which does not replace the Message-Id of the original message, but identifies Pine as the agent "bouncing" the message.
Resent-Date	This is the date when the message was bounced.
Resent-From	This is the address and personal name of the person that bounced the message to you. You can not edit the contents of this header, as you can with the From field.
Resent-To	This is the personal name and e-mail address of the person you are bouncing a message to.
Resent-Cc	The Cc field of the original message that was bounced.
Resent-Reply-To	The Reply-To field of the person bouncing the message.
Mime-Version	This is a string of the form "X.Y", indicating the version, which indicates the RFC number which Pine is following. In this case it refers to RFC 1521.
Content-Type	This is normally used to indicate how the message is structured. For example if the message contains attachemts, then this is set to "multipart", but if it's only text, it could be "text/plain" or "text/html", etc.
X-Post-Error	This header is generated if there was an error to post the message, and is saved in a message in the postponed-msgs folder. The contents of this field are displayed when you continue the message.
X-Reply-Uid	Internal header designated to contain information about a message. It is only found in messages in your postponed-msgs folder and its presence indicates that the message being postponed is a reply to another message. It's value is composed of three fields that are structured as follows: (Field1)(Field2)Field3 . The value of Field1 indicates the indent-string used to reply, and its length. Field3 contains the mailbox that the message being replied to was found and Field2 contains information on the location of the message being replied to in that mailbox.
X-Our-Reply-To	It indicates if there is a Reply-To header or not, by having values Full or Empty. Full indicates that Reply-To exists and is filled, and empty that this header does not exist.
X-Cursor-Pos	This header indicates where the cursor was located when the message was postponed. The number represented here indicates how many characters must Pine advance from the beginning of the message to reach its last known position.

Setting Headers when Reading a Message

You can choose which headers are displayed by default when you view a message. The default is that only the Date:, From:, To:, Cc:, Newsgroups: and Subject:. You can add headers to this list by adding them in the Viewer-hdrs. Again notice that if adding a value here clears the default and you need to specify all the headers that you want visible in this case.

Finally notice that if you want to see all headers at once, all you need to do is to press H while reading the message that you want to see its headers. Notice that you need to have

[X] enable-full-headers-cmd

enabled in order to be able to do this. You may want to add at least the Followup-To header to this list.

C-Client Headers

The library used to build Pine also uses and maintains some special headers, one of them is not an "X-" type header. These are Status, X-Status, X-IMAP, X-Keywords and X-UID. Note that even though many of these headers may be present in a message, they are not passed by the library to Pine, so you can never see them through Pine. The only way to see them is by editing the file containing the message.

Below is a table describing these headers

Header Name Description

Status This header is used to indicated if a message is old. If the header is absent, then the message is considered new. If the header is present but it does not have any value at all, again the message is considered new. If the value of this header contains the letter R, this indicates that the message has been Read (it really means that Pine requested to open that message, not that you actually read it. Pine can not know if you read and understood the message. I'm glad that there is no header for that!), if it contains the letter O, it means that the message is Old, which means that it was present in that mailbox in a previous session. Note that when searching for new messages, Pine looks for messages without the value of RO in this field (or for messages without this field). In its default configuration, Pine displays in its index as new (which means that a letter N is used to indicate the status of a message), for messages that do not have a R as the value of this header. This is very misleading, as it confuses some people as to why TAB can not find new messages in the incoming-folders collection, when there are messages marked new in that folder.

X-Status The value of this field contains information of IMAP flags set on the message. The possible values are ADFT. If the value of this header contains the letter A, it means that this message was Answered. The value D indicates that the message was marked Deleted. The value F is used to indicate that the message was Flagged. In Pine this value is interpreted as if the message is Important, and finally the value T is used to indicate that the message is a drafT. This last flag is not used by Pine. Notice that you can add Status and X-Status to your composer-hdrs and send messages to your friends with values in these headers. If they are using the UW-IMAP server, they will see their messages flagged in strange ways. There was a vulnerability found in previous versions of the UW-IMAP server if you sent messages containing one of these headers, with special information in it. This vulnerability is not present in the current version of UW-IMAP.

X-UID This is an internal number of the message in the folder. In the UW imap server (and local folders in Pine) the first message gets the value 1, the second message 2, and so on. Although, it is only required that the UID be increasing (so it could be indexed by prime numbers only!) The insteresting thing about this header is that even if you delete the message with uid 2, the next message will receive uid equal to 3. Therefore, when reading the list of X-UID you may find evidence that there are missing messages in the folder. If you want to regenerate the UIDs simply give the last message a X-UID equal to 1 and reopen the folder. UIDs will be generated automatically. By the way, UID stands for "Unique IDentifier".

X-Keywords These header contains strings used by the client, in general, to store extra information about the message. For example, a client may use a keyword Later to indicate that it must flag that particular message with a special flag that indicates that the user would read the message later.

X-IMAP This header contains the time that the folder was last accessed by the user (using the server or Pine) and the last X-UID assigned. This header may also contain keywords used in this folder. This header is only present in the pseudo message that Pine generates. In fact, if you add this header (and a valid value to it), to the first message of the folder, Pine will hide that message from you.

X-IMAPbase This header contains the time that the folder was last accessed by the user (using the server or Pine) and the last X-UID assigned. This header may also contain keywords used in this folder. This header is only present in the first message of the folder and its presence indicates that there is no pseudo message in the folder.

You are in Home > Miscellaneous > Headers

Header Name	Description
Status	This header is used to indicated if a message is old. If the header is absent, then the message is considered new. If the header is present but it does not have any value at all, again the message is considered new. If the value of this header contains the letter R, this indicates that the message has been Read (it really means that Pine requested to open that message, not that you actually read it. Pine can not know if you read and understood the message. I'm glad that there is no header for that!), if it contains the letter O, it means that the message is Old, which means that it was present in that mailbox in a previous session. Note that when searching for new messages, Pine looks for messages without the value of RO in this field (or for messages without this field). In its default configuration, Pine displays in its index as new (which means that a letter N is used to indicate the status of a message), for messages that do not have a R as the value of this header. This is very misleading, as it confuses some people as to why TAB can not find new messages in the incoming-folders collection, when there are messages marked new in that folder.
X-Status	The value of this field contains information of IMAP flags set on the message. The possible values are ADFT. If the value of this header contains the letter A, it means that this message was Answered. The value D indicates that the message was marked Deleted. The value F is used to indicate that the message was Flagged. In Pine this value is interpreted as if the message is Important, and finally the value T is used to indicate that the message is a drafT. This last flag is not used by Pine. Notice that you can add Status and X-Status to your composer-hdrs and send messages to your friends with values in these headers. If they are using the UW-IMAP server, they will see their messages flagged in strange ways. There was a vulnerability found in previous versions of the UW-IMAP server if you sent messages containing one of these headers, with special information in it. This vulnerability is not present in the current version of UW-IMAP.
X-UID	This is an internal number of the message in the folder. In the UW imap server (and local folders in Pine) the first message gets the value 1, the second message 2, and so on. Although, it is only required that the UID be increasing (so it could be indexed by prime numbers only!) The insteresting thing about this header is that even if you delete the message with uid 2, the next message will receive uid equal to 3. Therefore, when reading the list of X-UID you may find evidence that there are missing messages in the folder. If you want to regenerate the UIDs simply give the last message a X-UID equal to 1 and reopen the folder. UIDs will be generated automatically. By the way, UID stands for "Unique IDentifier".
X-Keywords	These header contains strings used by the client, in general, to store extra information about the message. For example, a client may use a keyword Later to indicate that it must flag that particular message with a special flag that indicates that the user would read the message later.
X-IMAP	This header contains the time that the folder was last accessed by the user (using the server or Pine) and the last X-UID assigned. This header may also contain keywords used in this folder. This header is only present in the pseudo message that Pine generates. In fact, if you add this header (and a valid value to it), to the first message of the folder, Pine will hide that message from you.
X-IMAPbase	This header contains the time that the folder was last accessed by the user (using the server or Pine) and the last X-UID assigned. This header may also contain keywords used in this folder. This header is only present in the first message of the folder and its presence indicates that there is no pseudo message in the folder.