Node:Aux-Item Types, Next:Name Expansion, Previous:Error Codes, Up:Top

Aux-Item Types

Some of the aux-items below (mostly the ones that begin with "mx-") are used by mail importers.

content-type [1] (text)

Specifies the content type of a text. Data is a valid MIME type or one of the special LysKOM types (see LysKOM Content Types).

This item may only be set by the author of a text. The inherit, secret and hide-owner bits are cleared. Only one content-type item can be created per creator.

fast-reply [2] (text)

Data is a string that constitutes a brief comment to the text. This comment should be displayed immediately after the text body.

An item of this type will never be inherited, can always be deleted, is never anonymous and is never secret.

cross-reference [3] (text, conference, letterbox)

Data is a cross-reference to something else. The contents consist of a letter, a number, and optionally a space and a descriptive text. The letter must be one of T, C or P. T specifies that the cross-reference points to a text; C that it points to a conference; and P that it points to a person. The number is the id of the target of the cross reference. The descriptive text is simply that, a text that describes the cross-reference. For example, "T15 Check this out!" is a cross reference to text 15 with a description that reads "Check this out!", and "T17" is a cross reference without a description.

The inherit bit is automatically cleared and the item can always be deleted.

no-comments [4] (text)

When this item is set, the author requests that nobody comments the text. This is advisory only; it is still possible to write comments, but clients should advise the user that this is contrary to the author's wishes. Data should be empty.

This item may only be set by the author. The secret, hide-creator and inherit bits are automatically cleared.

personal-comment [5] (text)

When this item is set, the author requests only personal comments. This is advisory only; it is still possible to create regular comments, but clients should advise the user that the author prefers a personal comment. Data should be empty.

This item may only be set by the author. The secret, hide-creator and inherit bits are automatically cleared.

request-confirmation [6] (text)

The author requests that everyone who reads the text confirms having done so by creating read-confirmation items on the text. Clients should ask users if they wish to confirm having read the text when it is displayed. Data should be empty.

The hide-creator, secret and inherit bits are automatically cleared.

read-confirm [7] (text)

This item can be taken as confirmation that the item creator has read the text to which the item is attached. Clients should never ever create this item without an explicit confirmation from the user that the text has indeed been read.

The hide-creator, secret and inherit bits are automatically cleared. Once created an item of this type cannot be deleted.

redirect [8] (conference, letterbox)

This item indicates that texts should not be sent to the conference, but be directed to some other target instead. Clients should notify users that attempt to send texts to the conference of the redirect and offer to send the text to the target of the redirect instead. A typical use of this item would be a user that does not read LysKOM very often and would like to advise other users to send e-mail instead.

Data is PROTOCOL:ADDRESS where PROTOCOL is either "E-mail" or "LysKOM", and ADDRESS is either an e-mail address or a LysKOM conference number. Hopefully we'll be able to replace this with a forwarding mechanism later.

This item can only be set by the conference supervisor or in the case of a mailbox, the person attached to the mailbox. The hide-creator and secret bits are cleared automatically. Only one redirect can be specified.

x-face [9] (conference, letterbox, server)

Data is the face of the person in compface format. Cool, innit?

This item can only be set by the conference supervisor or in the case of a mailbox, the person attached to the mailbox. The hide-creator and secret bits are cleared automatically.

alternate-name [10] (text, conference, letterbox)

Data is a string that the client may use as an alternate to the name of a conference or the subject of a text. Note that the server does not match against this name when performing name lookups. Clients should only display alternate names created by the user currently logged on.

The inherit flag is automatically cleared.

pgp-signature [11] (text)

Data is a PGP signature of the text. The signature should be the equivalent of what pgp -sba in PGP 2.6.2 generates.

The secret, hide-creator and inherit bits are automatically cleared. Signatures cannot be deleted once they have been created.

pgp-public-key [12] (letterbox)

Data is the public key of the person. It is desirable that the public key contains a userid of the format "LysKOM <pn@server>+", where n is the number of the person in the LysKOM server specified in server. This rule is currently not enforced.

This item can only be set by the person himself. The hide-creator, secret and inherit bits are automatically cleared.

e-mail-address [13] (conference, letterbox, server)

Data is an RFC 822-style email address. When set on a mailbox, it should be the email address of the person. If the person has multiple email addresses he may set several e-mail-address aux-items.

The meaning of this aux-item when set on a conference that isn't a mailbox is vague. For a conference that is used as to import a mailing list this should be the email address of the list. For other conferences we haven't really defined a sensible use.

When this aux-item is set on the server it should contain the email address of the administrator (or administrators.)

This aux-item can only be set by the supervisor of a conference or the server administrator. The creator cannot be hidden.

faq-text [14] (conference, letterbox, server)

Data is a decimal text number, which is a FAQ for the conference, letterbox or server. Creating an item of this type automatically causes creation of a faq-for-conf item.

This item can only be set by the supervisor or server administrator. The hide-creator, secret, and inherit bits are automatically cleared.

creating-software [15] (text)

Data is the name and version number of the client that created the text. This aux-item can only be set by the author of the text. Once set, it cannot be removed or changed. A typical value would be elisp-client 0.47.3. Setting the creating-software aux-item is optional.

The data should be the client name, a space, and the client version used in the set-client-version call. The server may enforce this restriction.

mx-author [16] (text)

Data is a string containing the name of the author of an imported e-mail, extracted from the From header. This aux-item may be missing, if the mail address in the From header consists of just the addr-spec (see the next aux-item).

Clients should display this instead of the actual author of the text (which will be an importer ID) even if an mx-from aux-item is not present.

Sample contents: Joe Q. Public which may come from a From header containing "Joe Q. Public" <john.q.public@example.com>.

mx-from [17] (text)

Data is the proper e-mail address (called addr-spec in the mail standards) extracted from the From header of an imported e-mail.

Clients should display this address together with the mx-author, preferably inside angles. If mx-author is not present, this address should be shown anyway. It can also be used by clients to construct an address for personal (e-mail) replies to an imported message.

Sample contents: john.q.public@example.com which may come from a From header containing john.q.public@example.com or something like "Joe Q. Public" <john.q.public@example.com>.

mx-reply-to [18] (text)

Data is the proper e-mail address (called addr-spec in the mail standards) extracted from the Reply-To header of an imported e-mail. Clients should use this for constructing replies to imported messages.

mx-to [19] (text)

Data is a single e-mail address from an email To header. Multiple mx-to items may be present when multiple recipients are specified in the header. Clients should display these items along with the normal LysKOM recipient headers.

Sample contents: Both john.q.public@example.com and "Joe Q. Public" <john.q.public@example.com> are valid.

mx-cc [20] (text)

Same as mx-to, but applies to the CC header rather than the To header.

mx-date [21] (text)

Data is the date and time from the Date header of an imported email. Its format is "YYYY-MM-DD hh:mm:ss TZ". YYYY is the year the message was sent, MM is the month, DD is the day, hh is the hour, mm is the minute and ss is the second. This date and time are given in the timezone where the message was sent. TZ is the timezone the date is valid for. It must be of the form "+hhmm" or "-hhmm", where hh is the number of hours offset from UTC and mm is the number of minutes offset. Symbolic timezones are not permitted. The timezone specification is recommended but optional, since it is not always available.

Clients should display this information as the date and time a text was written, since the imported text will have been created at a later time. The date and time when the message was imported would then be displayed elsewhere or not at all.

mx-message-id [22] (text)

Data is the Message-ID header of an imported e-mail, with whitespace and comments removed. The Message-ID should contain the surrounding angles.

mx-in-reply-to [23] (text)

Data is a string containing one item of the same form as the mx-message-id item described above. This is the Message-ID of another mail the current text is a comment to.

Hopefully, this information comes from the In-Reply-To header of the imported e-mail, but it could also have been picked from the end of the References header line.

If the text really comments more than one other text directly, it is allowed to attach more than one mx-in-reply-to items to it.

mx-misc [24] (text)

Data is a string that contains all of the headers of an imported email, including Subject, and including those that are redundantly stored in other aux-items. The headers are concatenated with "\n". In other words, this item contains all headers of an imported e-mail as they appear in the message.

Clients are encouraged to provide a command to display this information.

mx-allow-filter [25] (conference, letterbox)

This aux-item has been declared obsolete. It was intended to supply the importer with information on how to filter incoming messages based on regular expressions matching header lines.

mx-reject-forward [26] (conference, letterbox)

This aux-item has been declared obsolete. It was intended to supplement mx-allow-filter by telling where rejected mails should be sent.

notify-comments [27] (letterbox)

Data is a decimal text number that the user is interested in. Clients should monitor this text for unread comments and present these to the user in some convenient manner. This is typically used by users that want to read comments to some text of theirs as soon as they arrive, rather than in the normal reading order.

This item can only be set by the owner of the letterbox. No flags are forced or cleared.

faq-for-conf [28] (text)

Data is a decimal number specifying the conference a certain text is a FAQ for. The special number zero denotes that the text is a FAQ for the entire system. Items of this kind can only be created by the LysKOM server itself. Texts with this item are protected from garbage collection.

recommended-conf [29] (server)

Data is a decimal number specifying a conference that new members should automatically be added to, optionally followed by a space and a recommended priority, optionally followed by a space and a membership type. In the future, additional data may be defined; clients should be prepared to accept and ignore a space and any trailing data that may follow the membership type.

A few examples might clarify what the data may look like:

1

Conference number 1.

2 32

Conference number 2, with priority 32.

3 250 11100000

Conference number 3, with priority 250. The membership should be secret, passive and have the invitation bit set.

4 253 01000000 garbage

Conference number 4, with priority 253. The membership should be passive. The client should ignore the trailing garbage; it is reserved for future extensions. Note that clients are not allowed to create aux-items of this format, but they should be prepared to handle them correctly.

This is a recommendation only; it is up to the client that creates a new person to also add him to the conferences that are specified via recommended-conf.

allowed-content-type [30] (conference, letterbox, server)

Data is a non-negative decimal priority number, followed by a space, followed by a LysKOM content type glob pattern. Clients should send texts to a conference only if the content-type matches any of the allowed-content-type glob patterns of that conference.

If the conference doesn't have any allowed-content-type, the allowed-content-type items of the server should be used. If the server also has no allowed-content-type aux-items, it should be interpreted as if a single allowed-content-type aux-item with the value 1 text/plain exists.

If there are allowed-content-type aux-items with different priority numbers, it is a hint to the client about which content-type is most desirable. Content-types that matches a lower priority number are preferred.

As an example, consider a conference with the following four allowed-content-type aux-items:

1 text/plain
2 text/x-kom-basic
2 text/enriched
3 text/*

These aux-items taken together means that text/plain is preferred, that text/x-kom-basic and text/enriched can be used if there is a reason why text/plain is inadequate, and that any text type (such as text/html) is acceptable. Other content types, such as x-kom/user-area, should not be used.

The server does not currently enforce the above restriction on the content type of new texts. This mechanism is currently a hint to the client (or to the author of a new text). This may change in the future, if experience shows that it is desirable to have the server enforce the content type.

canonical-name [31] (server)

This should be set to the official domain name of the server, optionally followed by a colon and the port number. The port number should only be used if a non-standard port is used. Examples: kom.lysator.liu.se:8300, kom.lysator.liu.se. The intent is that the canonical-name should be globally unique among all LysKOM servers. Only a single aux-item of this type can be set on the server. This aux-item can be used by clients that wish to do certain things only when connected to a specific server.

mx-list-name [32] (conference)

This item should only be used if the main purpose of the conference is to import a single external mailing list. The data should be the email address that is used to post to the list, such as bug-lyskom@lysator.liu.se.

send-comments-to [33] (letterbox)

Normally, when a comment is created, the LysKOM client adds the author of the commented text to the recipient list if he isn't a member of any of the recipients of the comment. By setting this aux-item on the letterbox, a person can request different treatment.

Data is a decimal integer (a conference number) optionally followed by a space character and a decimal number (a recipient type). In the future, additional data may be defined; clients must be prepared to accept and ignore a space and any trailing data that may follow the recipient type. Clients must be prepared to accept items of this type that contain only the conference number.

Comments should be sent to the specified conference number instead of to the author. The value 0 is special and means that the comment should not be sent to any special conference, even though that means that the author of the commented text will never see the comment. (The value 0 is useful for mail importers and other similar robots.)

The recipient type is the type of recipient to add. If the recipient type is missing, clients should either assume recipient type zero (recpt) or ask the user. Legal recipient types are 0 for recpt, 1 for cc-recpt and 15 for bcc-recpt (these are the values used in Info-Type). Additional recipient types may be added in the future. Clients should treat unknown or invalid recipient types as if they were missing (i.e. treat them as zero or ask the user).

See Recipients of comments, for more information about how the client should select the conferences that a comment should be sent to.

This aux-item can only be set by the supervisor of the person.

world-readable [34] (text)

Texts that has this aux-item set on them can be read by everybody. It is not even necessary to log in.

Only the author of the text can set this item. The data must be the empty string. The hide-creator, secret, dont-garb and inherit bits are automatically cleared.

mx-refuse-import [35] (conference, letterbox)

This item tells the importer under what circumstances mail should be imported to the conference or letterbox. If no aux-item of this type is present, there are no limitations on import to this conference or letterbox.

If the data is the string all, the importer will never add this conference or letterbox as a recipient.

If the data is the string spam, the importer will not add this conference or letterbox as a recipient if the mail is considered to be spam according to some importer specific criteria (such as the presence of SpamAssassin flags).

In the future, other alternatives in addition to the above may be defined for this aux-item. An importer should silently ignore unrecognized ones. If more than one aux-item of this type is present, they will be combined in the most restrictive way, i.e. the recipient will not be added if any of the aux-items forbids import.

Clients are encouraged to provide commands to manage aux-items of this type for conferences and letterboxes.

mx-mime-belongs-to [10100] (text)

Data is a decimal text number that this text is an attachment to. Most likely, the current text is also a comment (or perhaps a footnote) to the text mentioned in the aux-item. A client can use this aux-item to alter the display format of the text (stating that this is an attachment, not a normal comment).

mx-mime-part-in [10101] (text)

Data is a decimal text number of a text that is an attachment to the current one. In other words: this is the converse of mx-mime-belongs-to. A client can use this aux-item to know which comments to mark as attachments; the remaining comments are assumed to be normal.

mx-mime-misc [10102] (text)

Data is a string that contains all of the MIME headers for the current text. It is set by the importer. The fields are concatenated with "\n".

Clients are encouraged to provide a command to display this.

mx-envelope-sender [10103] (text)

Data is the envelope sender of an imported text. The mail server is supposed to pass this information to the importer, for inclusion here.

mx-mime-file-name [10104] (text)

Data is the file name of an attachment. Most likely, the importer gets this information from a name parameter on a Content-Type MIME header line.

Clients are encouraged to use this file name as the default file name when the user chooses to save the text.

See also Some Client-specific Aux-Item Types, for information about some non-standardized aux-item types.