Sieve Notification Mechanism: mailtoIBM T.J. Watson Research Center19 Skyline DriveHawthorneNY10532US+1 914 784 7941leiba@watson.ibm.comfreenet AGWillstaetter Str. 13DuesseldorfNRW40549Germany+49 241 53087 520michael.haardt@freenet.ag
Applications
Sieve Working GroupSieveemailfilternotifications
This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent by electronic mail.
The extension to the
mail filtering language is a framework for providing notifications
by employing URIs to specify the notification mechanism.
This document defines how URIs are
used to generate notifications by e-mail.
Conventions for notations are as in section 1.1, including
the use of .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
The mailto mechanism results in the sending of a new email message
(a "notification message") to notify a recipient about a "triggering message".
The mailto notification mechanism uses standard mailto URIs
as specified in .
The notify_method_capability test for "online" may return "yes" or "no"
only if the Sieve processor can determine with certainty whether or
not the recipients of the notification message are online and logged in.
Otherwise, the test returns "maybe" for this notification method.
The :from tag overrides the default sender of
the notification message. "Sender", here, refers to the value
used in the "From" header. Implementations
MAY also use this value in the "MAIL FROM"
command (the "envelope sender"), or they may prefer to establish a mailbox that receives
bounces from notification messages.
The :importance tag has no special meaning for this notification mechanism,
and this specification puts no restriction on its use.
Implementations MAY use the value of :importance to set a
priority or importance indication on the notification message (perhaps
a visual indication, or perhaps making use of one of the non-standard
but commonly used message headers).
This tag is not used by the mailto method.
The value of this tag, if it is present, is used as the subject of the notification
message, and overrides all other mechanisms for determining the subject (as described below).
Its value SHOULD NOT normally be truncated, though it may be sensible
to truncate an excessively long value.
Because the receipt of an email message is generating another
email message, implementations MUST take steps to avoid mail loops.
The notification message contains the "Received:" fields from
the triggering message to allow loop detection as
described in , section 6.2.
The REQUIRED inclusion of an "Auto-Submitted:" field,
as described in the message composition guidelines, will also help
in loop detection and avoidance.
Implementations MUST NOT trigger notifications for messages containing
"Auto-Submitted:" header fields with any value other than "No".
Implementations MUST allow messages with empty envelope
senders to trigger notifications.
Because this notification method uses a store-and-forward system
for delivery of the notification message, the Sieve processor should not
have a need to retry notifications. Therefore, implementations of this method SHOULD
use normal mechanisms for submitting SMTP messages and for retrying
the initial submission. Once the notification message is submitted, implementations
MUST NOT resubmit it, as this is likely to result in multiple notifications, and
increases the danger of message loops.
The overall notification message is composed using the following
guidelines (see for references to message header fields):
If the envelope sender of the triggering message is
empty, the envelope sender of the notification
message MUST be empty as well, to avoid message loops.
Otherwise, the envelope sender of the notification
message SHOULD be set to the value of the ":from" parameter
to the notify action, if one is specified, has email address
syntax and is valid according to the implementation specific
security checks (see Section 3.3 of ).
If ":from" is not specified or is not valid,
the envelope sender of the notification
message SHOULD be set either to the envelope "to" field from the triggering
message, as used by Sieve, or to a fixed email address (so it
"comes from the notification system"), at the
discretion of the implementation. This may not be overridden
by a "from" URI header, and any such URI header MUST be ignored.
The header field "Auto-Submitted: sieve-notify" MUST be included in
the notification message (see ). This is to
reduce the likelihood of message loops, by tagging this as an automatically
generated message. Among other results, it will cause the notification
message not to generate further notifications. mailto URI headers with
hname "auto-submitted" are considered unsafe and MUST be ignored.
The "From:" header field of the notification message
SHOULD be set to the value of the ":from" parameter
to the notify action, if one is specified, has email address
syntax and is valid according to the implementation specific
security checks (see Section 3.3 of ).
If ":from" is not specified or is not valid,
the "From:" header field of the notification
message SHOULD be set either to the envelope "to" field from the triggering
message, as used by Sieve, or to a fixed email address (so it
"comes from the notification system"), at the
discretion of the implementation. This may not be overridden
by a "from" URI header, and any such URI header MUST be ignored.
The "To:" header field and the envelope recipient(s) of the notification message
SHOULD be set to the address(es) specified in the URI (including any URI headers
where the hname is "to").
The "Subject:" field of the notification message MUST contain the
value defined by the :message notify tag, as described in .
If there is no :message tag and there is a "subject" header on the
URI, then that value SHOULD be used. If that is also absent,
the subject SHOULD be retained from the triggering message.
Note that Sieve can be used to advantage here, as shown
in the example in .
If the mailto URI contains a "body" header, the value of
that header SHOULD be used as the body of the notification message.
If there is no "body" header, it is up to the implementation
whether to leave the body empty or to use an excerpt of the original
message.
The "Received:" fields from the triggering message MAY be retained
in the notification message, as these may help detect and prevent
mail loops. The "Auto-Submitted" header field MUST be placed above
these (see ).
URI headers with hname "received" are considered unsafe, and will be ignored.
Other header fields of the notification message that are normally related to
an individual new message (such as "Message-ID" and "Date") are generated
for the notification message in the normal manner, and MUST NOT be copied
from the triggering message. Any URI headers with
those names MUST be ignored. Further, the "Date" header serves as the
notification timestamp defined in .
All other header fields of the notification message either are as
specified by URI headers, or have implementation-specific values;
their values are not defined here. It is suggested that the
implementation capitalize the first letter of URI headers
and add a space character after the colon between the
mail header name and value when adding URI headers to the
message, to be consistent with common practice in email headers.
The header field "Auto-Submitted: sieve-notify" MUST be included in
the notification message (see ).
The "Auto-Submitted" header field is considered a "trace field", similar to
"Received" header fields (see ). If the implementation
retains the "Received" fields from the triggering message (see above), the
"Auto-Submitted" field MUST be placed above those "Received" fields, serving as
a boundary between the ones from the triggering message and those that will be part
of the notification message.
The sieve-notify Auto-Submitted field MAY include one or both of
the following OPTIONAL parameters:
owner-email - specifies an email address of the owner of the Sieve script
that generated this notification. If specified, it might be used to identify
or contact the script's owner.
The parameter attribute is "owner-email", and
the parameter value is a quoted string containing an email address, as defined
by "addr-spec" in .
Example:
Auto-Submitted: sieve-notify; owner-email="me@example.com"
owner-token - specifies an opaque token that the administrative domain of
the owner of the Sieve script that generated this notification can identify
the owner with. This might be used to allow identification of the owner
while protecting the owner's privacy.
The parameter attribute is "owner-token", and
the parameter value is as defined by "token" in .
Example:
Auto-Submitted: sieve-notify; owner-token=af3NN2pK5dDXI0W
Note that:
Fields such as "Message-ID:" and "Date:" were generated
afresh for the notification message, and do not relate to
the triggering message.
Additional "Received:" fields will be added to the
notification message in transit; the ones shown were
copied from the triggering message.
If this message should appear at the mail.example.org
server again, the server can use the presence of a
"mail.example.org" received line to recognize that.
The Auto-Submitted header field is also present to tell
the server to avoid sending another notification, and
it includes an optional owner-email parameter for identification.
This specification introduces no specific internationalization
issues that are not already addressed
in
and in .
Sending a notification is comparable with forwarding mail to the
notification recipient. Care must be taken when forwarding mail
automatically, to ensure that confidential information is not sent
into an insecure environment.
The automated sending of email messages exposes the system to
mail loops, which can cause operational problems. Implementations
of this specification MUST protect themselves against mail loops (see ).
Additional security considerations are discussed
in
and in .
The following template specifies the IANA registration of the
Sieve notification mechanism specified in this document:
To: iana@iana.org
Subject: Registration of new Sieve notification mechanism
Mechanism name: mailto
Mechanism URI: RFC2368
Mechanism-specific tags: none
Standards Track/IESG-approved experimental RFC number: this RFC
Person and email address to contact for further information:
Michael Haardt <michael.haardt@freenet.ag>
This information should be added to the list of sieve notification
mechanisms given on http://www.iana.org/assignments/sieve-notification.
Because does not define a registry for new
keywords used in the Auto-Submitted header field, we define one here, to be
created as http://www.iana.org/assignments/auto-submitted-keywords.
This defines the template to be used to register new keywords.
To: iana@iana.org
Subject: Registration of new auto-submitted header field keyword
Keyword value: [the text value of the field]
Description: [a brief explanation of the purpose of this value]
Parameters: [list any keyword-specific parameters, specify their meanings,
specify whether they are required or optional; use "none" if there are none]
Standards Track/IESG-approved experimental RFC number: [identifies
the specification that defines the value being registered]
Contact: [name and email address to contact for further information]
The following are the initial keywords to be registered for the Auto-Submitted
header field, to be entered in http://www.iana.org/assignments/auto-submitted-keywords.
Keyword value: no
Description: Indicates that a message was NOT automatically generated,
but was created by a human. It is the equivalent to the absence of an
Auto-Submitted header altogether.
Parameters: none
Standards Track/IESG-approved experimental RFC number: RFC3834
Contact: Keith Moore <moore@cs.utk.edu>
Keyword value: auto-generated
Description: Indicates that a message was generated by an automatic
process, and is not a direct response to another message.
Parameters: none
Standards Track/IESG-approved experimental RFC number: RFC3834
Contact: Keith Moore <moore@cs.utk.edu>
Keyword value: auto-replied
Description: Indicates that a message was automatically generated as a
direct response to another message.
Parameters: none
Standards Track/IESG-approved experimental RFC number: RFC3834
Contact: Keith Moore <moore@cs.utk.edu>
Keyword value: sieve-notify
Description: Indicates that a message was generated by a Sieve
notification system.
Parameters: owner-email, owner-token. Both optional, both refer to the
owner of the Sieve script that generated this message. See the relevant
RFC for details.
Standards Track/IESG-approved experimental RFC number: this RFC
Contact: Michael Haardt <michael.haardt@freenet.ag>
Key words for use in RFCs to Indicate Requirement LevelsHarvard UniversityThe mailto URL schemeInternet Mail ConsortiumXerox CorporationNetscape CommunicationsSieve: An Email Filtering LanguageSendmail, Inc.Sieve Extension: NotificationsIsode LimitedIBM T.J. Watson Research CenterIBM T.J. Watson Research CenterMirapoint, Inc.Internet Message FormatQUALCOMM IncorporatedRecommendations for Automatic Responses to Electronic MailUniversity of TennesseeSieve Extension: VariablesUniversity of OsloSimple Mail Transfer ProtocolAT&T Laboratories