header field
Click on the red underlined text to get to the source
... the relevant information or performs the command directly. MTAs
generating the header fields SHOULD usually include a mailto based
command, in addition to any other protocols used, in order to support
...
...
The contents of the list header fields mostly consist of angle-
bracket ('<', '>') enclosed URLs, with internal whitespace being
...
... supporting applications. As the standard for URLs is extended, the
list header fields will gain the benefit of those extensions.
Additionally, the use of URLs provides access to multiple transport
protocols ...
... mailto" protocol [RFC2368] will be the focus of most use of the list
header fields. Use of non-mailto protocols should be considered in
light of those users who do not have access to the specified
...
... To allow for future extension, client applications MUST follow the
following guidelines for handling the contents of the header fields
described in this document:
...
... The List Header Fields ...
...
This document presents header fields which will provide the
command syntax description for the 'core' and key secondary
functions of most email ...
...
The List-Help field is the most important of the header fields
described in this document. It would be acceptable for a list
manager to include only this field, since by definition it SHOULD
...
... A list that is a sublist for another list in a nested mailing list
hierarchy will need to modify some of the List- header fields, while
leaving others as the parent list set them.
...
... Mail list processors should not allow any user-originated list header
fields to pass through to their lists, lest they confuse the user and
have the potential to create security problems ...
... equally to this protocol. Mail client applications should not support
list header field URLs which could compromise the security of the
...
... A.1. Multiple header fields vs. a single header field ...
... A.1. Multiple header fields vs. a single header field ...
...
Use of a single header field for transporting command meta-syntax was
rejected for a number of reasons.
...
... the end users' knowledge of that syntax and ability to use it even if
their client applications do not support the list header fields.
...
... transport of meta-syntax to the use of a single
header field also introduces complications with header field size
limitations. Most individual commands can easily be described in a
...
... meta-syntax to the use of a single
header field also introduces complications with header field size
limitations. Most individual commands can easily be described in a
single line, but describing a multitude of commands can take up many
...
... URL standard. If URLs support it,
then the List- header fields support it. This is another advantage of
using URLs as the building blocks for the list header fields ...
... header fields support it. This is another advantage of
using URLs as the building blocks for the list header fields.
...
...
Variables would allow the List- header fields to accommodate nearly
every existing list manager. However, it would immeasurably increase
the complexity of the entire proposal, and possibly involve
...
... While the unsubscribe and subscribe command header fields may not be
usable by those systems which require the use of variables, the help
field will still provide end users with a consistent point of access
...
... A.6. Why not use a specialized MIME part instead of header fields? ...
... for end users. It is also not as easy for many list servers to
implement MIME as it is to implement new header fields.
...
...
At what point are there just too many header fields? It really
varies on a list by list basis. On some lists, the majority of users
will never be aware of a field unless the client software ...
... user interface to it (akin to the Reply-To field).
On others, the users will often see the header fields of messages and
would be able to recognize the function of the URLs contained within.
...
...
The flexibility afforded by the protocol described in this document
(in that the header fields may be individually implemented as deemed
appropriate) provides list administrators with sufficient 'room to
...
...
The following implementation possibilities are suggested here to give
some idea as to why these new header fields will be useful, and how
they could be supported.
...
... unsubscribe, a third request help, etc. The commands would only be
available on messages containing the list header fields.
...
... On graphical systems which have menus, these commands could take the
form of a menu or sub-menu of items. For example, a "Lists" menu
might appear when viewing messages containing the header fields, with
items named "Subscribe", "Unsubscribe ...