RFC 5436

Sieve Notification Mechanism: mailto

📅 published January 2009, from ietf

RFC 5436: Sieve Notification Mechanism: mailto ✨

Network Working Group 🎀 Written by B. Leiba (IBM T.J. Watson Research Center) and M. Haardt (freenet.de GmbH) 💅 Category: Standards Track 🦋 Date: January 2009 🌸 Updates: 3834 (this one updates RFC 3834 🫶)

Status of This Memo 📜

okay so this one is an Internet standards track protocol for the Internet community 💖 It's asking for discussion and suggestions for improvements, so bring your ideas! For where it sits in the standardization process right now, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨ Also, distribution of this memo is unlimited, so share it with everyone 🌈

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🔥

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they were in effect on the day it was published 📜 Please read those carefully, bestie, because they spell out your rights and restrictions for this document 🧚

Abstract 🔮

This document describes a profile of the Sieve extension for notifications. Its whole purpose is letting notifications get sent by electronic mail 💌

Table of Contents 🗂️

1. Introduction ....................................................3
   1.1. Overview ...................................................3
   1.2. Conventions Used in This Document ..........................3
2. Definition ......................................................3
   2.1. Notify Parameter "method" ..................................3
   2.2. Test notify_method_capability ..............................3
   2.3. Notify Tag ":from" .........................................3
   2.4. Notify Tag ":importance" ...................................4
   2.5. Notify Tag ":options" ......................................4
   2.6. Notify Tag ":message" ......................................4
   2.7. Other Definitions ..........................................4
        2.7.1. The Auto-Submitted Header Field .....................6
3. Examples ........................................................7
4. Internationalization Considerations .............................8
5. Security Considerations .........................................9
6. IANA Considerations ............................................10
   6.1. Registration of Notification Mechanism ....................10
   6.2. New Registry for Auto-Submitted Header Field Keywords .....10
   6.3. Initial Registration of Auto-Submitted Header
        Field Keywords ............................................11
7. References .....................................................11
   7.1. Normative References ......................................11
   7.2. Informative References ....................................12

1. Introduction ✨

1.1. Overview 🫧

So the [Notify] extension to the [Sieve] mail filtering language is basically a framework for sending notifications. The trick is it uses URIs to pick which notification mechanism gets used 🧚 This document is the part that explains how [mailto] URIs get used to make notifications go out by email 💌

1.2. Conventions Used in This Document 📝

Notation conventions follow Section 1.1 of [Sieve], including the use of [Kwds] 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [Kwds]. These are the special requirement words, so keep an eye out for them! 👀

2. Definition 🌷

So here's the vibe: the mailto mechanism sends a brand new email message (a "notification message") to tell a recipient about a "triggering message" 💌

2.1. Notify Parameter "method" 🎀

The mailto notification mechanism uses standard mailto URIs, as specified in [mailto]. mailto URIs may contain header fields, and each one is a header name plus a value. These get called "URI headers" so they're not mixed up with "message headers" 🫶

2.2. Test notify_method_capability 🔍

The notify_method_capability test for "online" may return "yes" or "no", but only if the Sieve processor can be certain whether or not the recipients of the notification message are online and logged in 🥹 If it can't be sure, the test returns "maybe" for this notification method 🤷‍♀️

2.3. Notify Tag ":from" 💌

The ":from" tag overrides the default sender of the notification message ✨ "Sender" here means the value used in the [RFC5322] "From" header. Implementations MAY also use this value in the [RFC5321] "MAIL FROM" command (the "envelope sender"). Or they may prefer to set up a mailbox that catches bounces from notification messages instead 🦋

2.4. Notify Tag ":importance" 🔥

The ":importance" tag has no special meaning for this notification mechanism, and this specification puts no restriction on how it's used 🌈 Implementations MAY use the value of ":importance" to set a priority or importance indication on the notification message. That could be a visual indication, or it could use one of the non-standard but commonly used message headers 💅

2.5. Notify Tag ":options" 🙈

This tag is not used by the mailto method. Nothing to see here! 🍓

2.6. Notify Tag ":message" 💖

If the ":message" tag is present, its value becomes the subject of the notification message 🧚 It overrides all the other mechanisms for working out the subject (as described below) 👑 The value SHOULD NOT normally be truncated. It can be sensible to truncate an excessively long value though, so don't panic 😭

2.7. Other Definitions 🦋

okay so, receiving an email literally generates another email, which means loops are a real danger 😭 Implementations MUST take steps to avoid mail loops. The REQUIRED Auto-Submitted: field, described in the message composition guidelines, also helps with loop detection and avoidance 💅

Implementations SHOULD NOT trigger notifications for messages with an Auto-Submitted: header field whose value is anything other than No 🙈

Implementations MUST allow messages with empty envelope senders to trigger notifications ✨

This notification method uses store-and-forward for delivery, so the Sieve processor shouldn't really need to retry notifications 🧚 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. Resubmitting would likely cause multiple notifications and make message loops more dangerous 💀

Implementations SHOULD consider limiting notification messages. In particular, they SHOULD NOT send duplicate notifications to the same address from the same script invocation. Batching notifications to the same address within a short time might also help 🌸 Different implementations, administrative domains, and users all have different needs, so configuration options are a good idea here 🎀

The overall notification message is composed using these guidelines (see [RFC5322] 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 too, to avoid message loops. Otherwise, the envelope sender of the notification message SHOULD be set to the value of the :from tag on 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 [Notify]). 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 an email address associated with the notification system, depending on the implementation. This MUST NOT be overridden by a "from" URI header, and any such URI header MUST be ignored.
  • 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" or "cc".
  • The header field Auto-Submitted: auto-notified MUST be included in the notification message (see Section 2.7.1). This tags the message as automatically generated, which reduces the likelihood of message loops. Among other results, it tells other notification systems 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 tag on 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 [Notify]). If :from is not specified or is not valid, the From: header field SHOULD be set either to the envelope "to" field from the triggering message, as used by Sieve, or to an email address associated with the notification system, depending on the implementation. This MUST NOT be overridden by a "from" URI header, and any such URI header MUST be ignored.
  • The To: header field 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 SHOULD contain the value defined by the :message tag, as described in [Notify]. If there is no :message tag and there is a "subject" header on the URI, that value SHOULD be used. If the "subject" header is also absent, the subject SHOULD be retained from the triggering message. Sieve [Variables] can be used to great effect here, as shown in the example in Section 3 ✨
  • The References: field of the notification message MAY be set to refer to the triggering message, and MAY include references from the triggering message.
  • If the mailto URI contains a "body" header, that header's value SHOULD be used as the body of the notification message. If there is no "body" header, it's up to the implementation whether to leave the body empty or use an excerpt of the original message.
  • The Received: fields from the triggering message MAY be kept in the notification message, since they could give useful trace, history, and diagnostic info 🔍 The Auto-Submitted header field MUST be placed above these (see Section 2.7.1). URI headers with hname "received" are considered unsafe and MUST be ignored.
  • Other header fields that normally relate 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. The Date header also serves as the notification timestamp defined in [Notify] ⏰
  • All other header fields of the notification message either come from URI headers or have implementation-specific values, and their values aren't defined here. It's suggested that the implementation capitalize the first letter of URI headers and add a space after the colon between the mail header name and value when adding URI headers to the message. That matches common email header practice 💖

2.7.1. The Auto-Submitted Header Field 🎀

The header field Auto-Submitted: auto-notified MUST be included in the notification message (see [RFC3834]). The Auto-Submitted header field counts as a "trace field", similar to Received header fields (see [RFC5321]). If the implementation keeps the Received fields from the triggering message (see above), the Auto-Submitted field MUST be placed above those Received fields. That makes it a boundary between the fields from the triggering message and the ones that belong to the notification message 🚧

The header field Auto-Submitted: auto-notified MUST include one or both of the following parameters:

  • owner-email: specifies an email address, determined by the implementation, for 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 [RFC5322]. Example:
Auto-Submitted: auto-notified; owner-email="me@example.com"
  • owner-token: specifies an opaque token, determined by the implementation, that the administrative domain of the owner of the Sieve script that generated this notification can use to identify the owner. This might let the owner be identified while protecting their privacy. The parameter attribute is owner-token, and the parameter value is as defined by "token" in [RFC3834]. Example:
Auto-Submitted: auto-notified; owner-token=af3NN2pK5dDXI0W

See Section 5 for a discussion of possible uses of these parameters 🔐

3. Examples 🍓

Triggering message (received by recipient@example.org):

Return-Path: <knitting-bounces@example.com>
Received: from mail.example.com by mail.example.org
  for <recipient@example.org>; Wed, 7 Dec 2005 05:08:02 -0500
Received: from hobbies.example.com by mail.example.com
  for <knitting@example.com>; Wed, 7 Dec 2005 02:00:26 -0800
Message-ID: <1234567.89ABCDEF@example.com>
Date: Wed, 07 Dec 2005 10:59:19 +0100
Precedence: list
List-Id: Knitting Mailing List <knitting.example.com>
Sender: knitting-bounces@example.com
Errors-To: knitting-bounces@example.com
From: "Jeff Smith" <jeff@hobbies.example.com>
To: "Knitting Mailing List" <knitting@example.com>
Subject: [Knitting] A new sweater

I just finished a great new sweater!

Sieve script (run on behalf of recipient@example.org):

require ["enotify", "variables"];

if header :contains "list-id" "knitting.example.com" {
  if header :matches "Subject" "[*] *" {
    notify :message "From ${1} list: ${2}"
        :importance "3"
        "mailto:0123456789@sms.example.net?to=backup@example.com";
  }
}

Notification message:

Auto-Submitted: auto-notified; owner-email="recipient@example.org"
Received: from mail.example.com by mail.example.org
  for <recipient@example.org>; Wed, 7 Dec 2005 05:08:02 -0500
Received: from hobbies.example.com by mail.example.com
  for <knitting@example.com>; Wed, 7 Dec 2005 02:00:26 -0800
Date: Wed, 7 Dec 2005 05:08:55 -0500
Message-ID: <A2299BB.FF7788@example.org>
From: recipient@example.org
To: 0123456789@sms.example.net, backup@example.com
Subject: From Knitting list: A new sweater

Note that:

  • Fields such as Message-ID: and Date: were generated fresh for the notification message and don't 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. New ones will be added above the Auto-Submitted: header field.
  • If this message ever shows up at the mail.example.org server again, the server can spot it by the presence of a "mail.example.org" received line. The Auto-Submitted header field is also there to tell the server not to send another notification, and it includes an optional owner-email parameter for identification 🦋

4. Internationalization Considerations 🌍

This specification introduces no internationalization issues beyond those already addressed in [Sieve] and in [Notify] ✨

5. Security Considerations 🔐

Okay bestie, this part is serious, but we're gonna make it iconic 💅 Sending a notification is basically like forwarding mail to the person being notified. So whenever mail gets forwarded automatically, you gotta be careful that confidential info doesn't end up somewhere insecure 😭

The automated sending of email messages can cause mail loops, and those can cause real operational problems 🌀 Implementations of this specification MUST protect themselves against mail loops. Check Section 2.7 for the deets and some suggestions ✨ Other possible mitigations involve types of service limitations. For example, the number of notifications generated for a single user might be limited to no more than, say, 30 in a 60-minute period. But this technique has its own drama 🎭 The actual rate limit has to be picked carefully so that most legit situations still get through, and even with careful picking, false positives and false negatives are inevitable 🙈

Ultimately, a human might need to step in to re-enable notifications that got disabled because a loop was detected, or to shut down a very slow loop that slipped under the automatic detection radar 👀 Administrative mechanisms MUST be available to handle these situations.

Email addresses set as notification recipients might not be owned by the entity that owns the Sieve script 😬 So a recipient could end up getting unwanted notifications, either on purpose (someone using scripts to mount a mail-bomb attack) or by accident (an address was mistyped or got reassigned). This is arguably no worse than any other situation where someone gets unwanted email, and some of the same tools can help here too. But anyone deploying this extension has to be aware of the extra problems, especially where scripts get created in ways that don't properly validate email addresses, and those scripts then get forgotten and keep running forever 💀

Here's the big one: the Auto-Submitted header field is required to include a value that a recipient can use to contact the source domain of the notification message (see Section 2.7.1). That value lets the domain track down the script's owner and get the script fixed or disabled 🔧 Domains that enable this extension MUST be prepared to respond to these complaints, so a faulty script can't keep doing damage 🫶

Problems can also pop up if notification messages get sent to a gateway into another service, like SMS 📱 A lot of the information from the email message gets lost in gateway translation, and then the critical stuff needed to avoid loops, contact the script owner, and sort out other problems might be gone too. Developers of email gateways should think about these issues and try to preserve as much information as possible, including what shows up in email trace headers and the Auto-Submitted header field 🧚

Additional security considerations are discussed in [Sieve] and in [Notify] 📚

6. IANA Considerations 📝

6.1. Registration of Notification Mechanism

Here's the template for registering 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 options: none
Permanent and readily available reference: RFC 5436
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 available from http://www.iana.org 🌸

6.2. New Registry for Auto-Submitted Header Field Keywords

Because [RFC3834] doesn't define a registry for new keywords used in the Auto-Submitted header field, we made one here 🎀 It's been created and is available from http://www.iana.org. New keywords get registered using the "Specification Required" policy [IANA] ✨

This is the template to use when registering new keywords. The initial entries to this registry come right after it, in Section 6.3 💖

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]

Permanent and readily available reference: [identifies
   the specification that defines the value being registered]
Contact: [name and email address to contact for further information]

6.3. Initial Registration of Auto-Submitted Header Field Keywords

These are the initial keywords registered in the "Auto-Submitted Header Field Keywords" registry, available from http://www.iana.org 🌈

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
Permanent and readily available reference: RFC3834
Contact: Keith Moore <moore@network-heretics.com>

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
Permanent and readily available reference: RFC3834
Contact: Keith Moore <moore@network-heretics.com>

Keyword value: auto-replied
Description: Indicates that a message was automatically generated as
   a direct response to another message.
Parameters: none
Permanent and readily available reference: RFC3834
Contact: Keith Moore <moore@network-heretics.com>

Keyword value: auto-notified
Description: Indicates that a message was generated by a Sieve
   notification system.
Parameters: owner-email, owner-token.  At least one is required;
   both refer to the owner of the Sieve script that generated this
   message.  See the relevant RFC for details.
Permanent and readily available reference: RFC 5436
Contact: Michael Haardt <michael.haardt@freenet.ag>

7. References 📖

7.1. Normative References

[IANA]       Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 5226,
             May 2008.

[Kwds]       Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[Notify]     Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
             Martin, "Sieve Email Filtering: Extension for
             Notifications", RFC 5435, January 2009.

[RFC3834]    Moore, K., "Recommendations for Automatic Responses to
             Electronic Mail", RFC 3834, August 2004.

[RFC5322]    Resnick, P., Ed., "Internet Message Format", RFC 5322,
             October 2008.

[Sieve]      Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An
             Email Filtering Language", RFC 5228, January 2008.

[mailto]     Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
             URL scheme", RFC 2368, July 1998.

7.2. Informative References

[RFC5321]    Klensin, J., Ed., "Simple Mail Transfer Protocol",
             RFC 5321, October 2008.

[Variables]  Homme, K., "Sieve Extension: Variables", RFC 5229,
             January 2008.

Authors' Addresses 🫶

Barry Leiba
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY  10532
US

Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com


Michael Haardt
freenet.de GmbH
Willstaetter Str. 13
Duesseldorf, NRW  40549
Germany

Phone: +49 241 53087 520
EMail: michael.haardt@freenet.ag
📦 where this page comes from