draft-ietf-sieve-refuse-reject-08.txt   draft-ietf-sieve-refuse-reject-09.txt 
Sieve Working Group A. Stone, Ed. Sieve Working Group A. Stone, Ed.
Internet-Draft Serendipity Internet-Draft Serendipity
Obsoletes: 3028 (if approved) Obsoletes: 3028 (if approved)
Updates: 5228 (if approved) November 17, 2008 Updates: 5228 (if approved) November 17, 2008
Intended status: Standards Track Intended status: Standards Track
Expires: May 21, 2009 Expires: May 21, 2009
Sieve Email Filtering: Reject and Extended Reject Extensions Sieve Email Filtering: Reject and Extended Reject Extensions
draft-ietf-sieve-refuse-reject-08 draft-ietf-sieve-refuse-reject-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 31 skipping to change at page 2, line 31
2.1.2. Rejecting a message by sending a DSN . . . . . . . . . 5 2.1.2. Rejecting a message by sending a DSN . . . . . . . . . 5
2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Rejecting a message by sending an MDN . . . . . . . . 7 2.2.1. Rejecting a message by sending an MDN . . . . . . . . 7
2.3. Silent upgrade from reject to ereject . . . . . . . . . . 8 2.3. Silent upgrade from reject to ereject . . . . . . . . . . 8
2.4. Compatibility with other actions . . . . . . . . . . . . . 8 2.4. Compatibility with other actions . . . . . . . . . . . . . 8
2.5. Details of protocol level refusal . . . . . . . . . . . . 9 2.5. Details of protocol level refusal . . . . . . . . . . . . 9
3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 11 3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. reject extension registration . . . . . . . . . . . . . . 11 5.1. reject extension registration . . . . . . . . . . . . . . 11
5.2. ereject extension registration . . . . . . . . . . . . . . 11 5.2. ereject extension registration . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The Sieve mail filtering language, as originally defined in RFC 3028 The Sieve mail filtering language, as originally defined in RFC 3028
skipping to change at page 3, line 34 skipping to change at page 3, line 34
contributing to the flood of Joe-job spam to victims of Joe-jobs. By contributing to the flood of Joe-job spam to victims of Joe-jobs. By
rejecting the message at the protocol level, it is less likely that rejecting the message at the protocol level, it is less likely that
an MDN will be needed, and so less likely that an MDN will be an MDN will be needed, and so less likely that an MDN will be
misdirected at an innocent third-party. misdirected at an innocent third-party.
Implementations are further encouraged to use spam-detection systems Implementations are further encouraged to use spam-detection systems
to determine the level of risk associated with sending an MDN, and to determine the level of risk associated with sending an MDN, and
this document allows implementations to silently drop the MDN if the this document allows implementations to silently drop the MDN if the
rejected message is deemed to be likely spam. rejected message is deemed to be likely spam.
This document also specifies the use of a Delivery Status
Notification [DSN] instead of an MDN when appropriate. In general,
an MDN is generated by [[[arnt's text]]] while a DSN is generated by
[[[arnt's text]]].
This document also describes how to use reject/ereject at varying This document also describes how to use reject/ereject at varying
points in the email stack: Mail Transfer Agent (MTA), Mail Delivery points in the email stack: Mail Transfer Agent (MTA), Mail Delivery
Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a
comprehensive discussion of these environments. comprehensive discussion of these environments.
In general, an MDN is generated by an MUA, and can be used to
indicate the status of a message with respect to its recipient, while
a DSN [DSN] is generated by an MTA, and can be used to indicate
whether or not a message was received and delivered by the mail
system.
Further discussion highlighting the risks of generating MDNs and the Further discussion highlighting the risks of generating MDNs and the
benefits of protocol-level refusal can be found in [Joe-DoS]. benefits of protocol-level refusal can be found in [Joe-DoS].
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
Conventions for notations are as in RFC 5228 [SIEVEBIS] Section 1.1. Conventions for notations are as in RFC 5228 [SIEVEBIS] Section 1.1.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
Usage: reject <reason: string> Usage: reject <reason: string>
Sieve implementations that implement the "reject" action must use the Sieve implementations that implement the "reject" action must use the
"reject" capability string. "reject" capability string.
The "reject" action cancels the implicit keep and refuses delivery of The "reject" action cancels the implicit keep and refuses delivery of
a message. The reason string is a UTF-8 [UTF-8] string specifying a message. The reason string is a UTF-8 [UTF-8] string specifying
the reason for refusal. Unlike the "ereject" action described above, the reason for refusal. Unlike the "ereject" action described above,
this action would always favor preserving the exact text of the this action would always favor preserving the exact text of the
refusal reason. Typically the "reject" action refuses delivery of a refusal reason. Typically the "reject" action refuses delivery of a
message by sending back an MDN to the alleged sender (see message by sending back an MDN to the sender (see Section 2.2.1).
Section 2.2.1). However implementations MAY refuse delivery over However implementations MAY refuse delivery over SMTP/LMTP protocol
SMTP/LMTP protocol (as detailed in Section 2.5), if and only if all (as detailed in Section 2.5), if and only if all of the following
of the following conditions are true: conditions are true:
1. The reason string consists of only US-ASCII characters 1. The reason string consists of only US-ASCII characters
or or
The reason string contains non-US-ASCII and both client and The reason string contains non-US-ASCII and both client and
server support and negotiate use of an SMTP/LMTP extension for server support and negotiate use of an SMTP/LMTP extension for
sending UTF-8 responses. sending UTF-8 responses.
2. LMTP protocol is used 2. LMTP protocol is used
or or
SMTP protocol is used and the message has a single recipient SMTP protocol is used and the message has a single recipient
skipping to change at page 7, line 26 skipping to change at page 7, line 26
if size :over 100K { if size :over 100K {
reject text: reject text:
Your message is too big. If you want to send me a big attachment, Your message is too big. If you want to send me a big attachment,
put it on a public web site and send me an URL. put it on a public web site and send me an URL.
. .
; ;
} }
(Pretend that the reason string above contains some non-ASCII text.) (Pretend that the reason string above contains some non-ASCII text.)
Implementations may use techniques as described in Section 2.1 to
determine if a non-delivery report should not be sent to a forged
sender. Implementations SHOULD log instances when a non-delivery
report is not sent and the reason for not sending the report.
2.2.1. Rejecting a message by sending an MDN 2.2.1. Rejecting a message by sending an MDN
The reject action resends the received message to the envelope sender The reject action resends the received message to the envelope sender
specified by the MAIL FROM (or Return-Path) address, wrapping it in a specified by the MAIL FROM (or Return-Path) address, wrapping it in a
"reject" form, explaining that it was rejected by the recipient. "reject" form, explaining that it was rejected by the recipient.
Note that according to [MDN], Message Disposition Notifications MUST Note that according to [MDN], Message Disposition Notifications MUST
NOT be generated if the MAIL FROM (or Return-Path) is empty. NOT be generated if the MAIL FROM (or Return-Path) is empty.
A reject message MUST take the form of a failure MDN as specified by A reject message MUST take the form of a failure MDN as specified by
[MDN]. The human-readable portion of the message, the first [MDN]. The human-readable portion of the message, the first
component of the MDN, contains the human readable message describing component of the MDN, contains the human readable message describing
the error, and it SHOULD contain additional text alerting the the error, and it SHOULD contain additional text alerting the
apparent original sender that mail was refused by an email filter. apparent original sender that mail was refused by an email filter.
The MDN disposition-field as defined in the MDN specification MUST be The MDN disposition-field as defined in the MDN specification MUST be
"deleted" and MUST have the "MDN-sent-automatically" and "automatic- "deleted" and MUST have the "MDN-sent-automatically" and "automatic-
action" modes set (see Section 3.2.6 of [MDN]). action" modes set (see Section 3.2.6 of [MDN]).
In the following script, a message is rejected and returned to the In the following script, a message is rejected and returned to the
alleged sender. sender.
Example: Example:
require ["reject"]; require ["reject"];
if header :contains "from" "coyote@desert.example.org" { if header :contains "from" "coyote@desert.example.org" {
reject text: reject text:
I am not taking mail from you, and I don't I am not taking mail from you, and I don't
want your birdseed, either!" want your birdseed, either!"
. .
; ;
skipping to change at page 8, line 29 skipping to change at page 8, line 29
The message was refused by the recipient's mail filtering program. The message was refused by the recipient's mail filtering program.
The reason given was as follows: The reason given was as follows:
I am not taking mail from you, and I don't want your birdseed, I am not taking mail from you, and I don't want your birdseed,
either! either!
------------------------------------------------------------ ------------------------------------------------------------
2.3. Silent upgrade from reject to ereject 2.3. Silent upgrade from reject to ereject
Implementations MUST NOT silently upgrade reject actions to ereject Implementations MUST NOT silently upgrade reject actions to ereject
actions, however user interfaces may change the specific action actions in a Sieve script, because this might lead to unpleasant
underlying a descriptive representation, thereby effecting a silent changes of behavior not expected by the script owner.
upgrade of sorts.
User interfaces that present a generic rejection option, and generate
Sieve script output, MAY switch from generating reject to ereject
actions, so long as doing so does not create a confusing change for
the script owner.
Script generators SHOULD ensure that a rejection action being Script generators SHOULD ensure that a rejection action being
executed as a result of an anti-spam/anti-virus positive test be done executed as a result of an anti-spam/anti-virus positive test be done
using the ereject action, as it is more suitable for such rejections. using the ereject action, as it is more suitable for such rejections.
Script generators MAY automatically upgrade scripts that previously Script generators MAY automatically upgrade scripts that previously
used the reject action for anti-spam/anti-virus related rejections. used the reject action for anti-spam/anti-virus related rejections.
Note that such generators MUST make sure that the target environment Note that such generators MUST make sure that the target environment
can support the ereject action. can support the ereject action.
skipping to change at page 11, line 19 skipping to change at page 11, line 19
protocol level message rejection. protocol level message rejection.
Added the "ereject" action that is similar to "reject", but will Added the "ereject" action that is similar to "reject", but will
always favor protocol level message rejection. always favor protocol level message rejection.
4. Security Considerations 4. Security Considerations
The Introduction to this document discusses why rejecting messages The Introduction to this document discusses why rejecting messages
before delivery is better than accepting and bouncing them. before delivery is better than accepting and bouncing them.
While the details of techniques that can be used to determine when to
silently drop a non-delivery report are outside the scope of this
document, the explicit permission this document gives to take such
action may enable denial of service situations. Techniques such as
spam-checking, return-path verification, and others, can and do have
false-positives. Care should be exercised to prevent the loss of
legitimate messages by failing to notify the sender of non-delivery.
Security issues associated with email auto-responders are fully Security issues associated with email auto-responders are fully
discussed in the Security Considerations section of [RFC3834]. This discussed in the Security Considerations section of [RFC3834]. This
document is not believed to introduce any additional security document is not believed to introduce any additional security
considerations in this general area. considerations in this general area.
The "ereject" extension does not raise any other security The "ereject" extension does not raise any other security
considerations that are not already present in the base [SIEVE] considerations that are not already present in the base [SIEVE]
specification, and these issues are discussed in [SIEVE]. specification, and these issues are discussed in [SIEVE].
5. IANA Considerations 5. IANA Considerations
skipping to change at page 13, line 15 skipping to change at page 13, line 21
Vacation Extension", RFC 5230, January 2008. Vacation Extension", RFC 5230, January 2008.
6.2. Informative References 6.2. Informative References
[EMAIL-ARCH] [EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture", Crocker, D., "Internet Mail Architecture",
draft-crocker-email-arch-11 (work in progress), draft-crocker-email-arch-11 (work in progress),
October 2008. October 2008.
[Joe-DoS] Frei, S., Silvestri, I., and G. Ollman, "Mail Non-Delivery [Joe-DoS] Frei, S., Silvestri, I., and G. Ollman, "Mail Non-Delivery
Message DDoS Attacks", April 2004, <http:// Notice Attacks", April 2004, <http://www.techzoom.net/
www.techzoom.net/papers/ papers/mail_non_delivery_notice_attacks_2004.pdf>.
mail_non_delivery_notice_attacks_2004.pdf>.
[RFC3834] Moore, K., "Recommendations for Automatic Responses to [RFC3834] Moore, K., "Recommendations for Automatic Responses to
Electronic Mail", RFC 3834, August 2004. Electronic Mail", RFC 3834, August 2004.
[SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language",
RFC 3028, January 2001. RFC 3028, January 2001.
[SPAMTEST] [SPAMTEST]
Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Daboo, C., "Sieve Email Filtering: Spamtest and Virustest
Extensions", RFC 5235, January 2008. Extensions", RFC 5235, January 2008.
 End of changes. 10 change blocks. 
18 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/