[Top] [All Lists]

draft-elvey-refuse-sieve-00 (was Re: Sieve reject at SMTP time possible with which implementations?)

2003-10-29 16:17:11

On 10/25/2003 9:48 PM, ned(_dot_)freed(_at_)mrochek(_dot_)com sent forth 
electrons to convey:

> Of course nothing prevents an implementation from adding a separate action > other than reject for this. But SMTP level errors don't match up to sieve > actions very well. Why? Because sieve evaluation almost always requires having > the entire message on hand. In SMTP this means the only reponse code that's > left is the last one, where the server accepts or rejects the message on behalf > of all recipients. This becomes a problem when there are multiple recipients
> and some reject the message and some do not.

I would like to see such an action (Shall we call it "refuse"?) in the
next version of the spec, or in an extension.  Anyone else?
Something like "refuse MUST reject an email at the SMTP level, instead
of sending an MDN, where possible, as this would be an anti-Joe-Job feature"
It will otherwise behave like reject, but only permit a single line of
response text.  Issues of specifying response codes (4xx, 5xx, 4.x.x,
etc) would need to be hashed out, 'where possible' would address the
problem Ned raised, above.

It would have to be done as an extension; adding something like this to
the base specification isn't realistic at this point.

I personally would have no objection to this extension.

Here goes!

I hope someone here will help shepherd such an extension through the IETF process.

The procedure is rather overwhelming; while I'd like to contribute,
perhaps I need not become a certified IETF labyrinth navigator in the process. :) OTOH, there's a son-of-GTUBE EICAR-like standard I'd like to create, so if no one is willing, I can try to kill two birds with one stone. (Learn the skills to shepherd two specs, that is.)
If no one is willing, I'll need to figure out stuff like
Is there a WG for handling Sieve extensions? Do I need to be a paying IETF member (prohibitive cost?) Is there a good editor/emacs mode/Windows app for writing Internet-Drafts/RFCs? Put the following into the boilerplate, etc? I see Ned is a prolly very busy Apps director(!)

First draft! (With some commentary about open issues mixed in; I know it's not in the right format, and it's totally unedited, but I'm drained, so here goes.) Feedback welcomed by email or on-list.


MDNs cause returned Joe-job spam to hit the Joe-job victim's mailbox; SMTP level refusals usually don't. 'refuse' uses the latter method to return unwanted email.

In other words, Sieve should have the capability such that email may be flat out not accepted

during the SMTP transaction, instead of accepted, and then bounced back to the alleged sender (often, in the case of spam, a

Joe-Job victim).
The SIEVE mail filtering language [SIEVE] "refuse" extension, if supported, permits users to handle unwanted email in a

way that is sometimes preferable to the existing 'discard' and 'reject' capabilities. When a spam-detection system suspects

a message is spam, but isn't certain, discarding the email is considered too risky for some users, for example, those who

receive sales leads by email. They are willing to use the reject command. Users are willing to reject but not discard because the sender of an email incorrectly marked as spam will receive a notification that the email was refused, and will likely try again to contact the intended recipient, perhaps via another method of communication. Unfortunately, using is problematic, because in the usual case, the email is indeed spam, and the alleged sender to whom the MDN caused by the reject will be sent will often be an innocent "Joe-job" victim. 'Refuse' is intended to be superior to 'reject' because it

will be less likely to result in email to an innocent victim (a 'Joe-job'). 'refuse' refuses to accept an email for delivery instead of accepting it and then sending an MDN. Most spam is sent through open proxies, so 'refuse' eliminates most Joe-job bounces resulting from usage of reject. 'Reject' will also reduce Joe-jobs caused by virus self-propagation via emails with false sender information.

Change History (to be removed prior to publication as an RFC) Changes from -00 to -01: Table of Contents 1 Introduction and Overview . . . . . . . . . . . . . . . . . . 3
    2  Conventions Used in This Document  . . . . . . . . . . . . . . 3
    3  SIEVE Extensions  . . . . . . . . . . . . . . . . . . . . . .  4
      3.1  General Considerations . . . . . . . . . . . . . . . . . . 4
      3.2  Test spamtest . . . . . . . . . . . . . . . . . . . . . .  4

4 Security Considerations . . . . . . . . . . . . . . . . . . . 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5.1 spamtest registration . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6.2 Non-Normative References . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . .

    9  Intellectual Property Rights Statement . . . . . . . . . . . .
10 Full Copyright Statement . . . . . . . . . . . . . . . . . . 1 Introduction and Overview 'refuse' MUST refuse to accept for an email delivery at the SMTP level, instead of sending an MDN, other than for the specified exceptions. A SIEVE implementation that cannot do so MUST NOT claim to support the refuse extension.

Where the suspected spam source is believed to be an open relay (e.g. as determined by a RBLDNS lookup), the implementation MAY send an MDN when 'refuse' is indicated, as an MDN allows more opportunity for being handled in an automated fashion by its recipient because of its prescribed, relatively informative format. Systems that support the extension MUST encourage use of "refuse" over 'discard' and 'reject' where it is an appropriate alternative.
"Extensions which define actions MUST state how they interact with
  actions discussed in the base specification." - [SIEVE]

Reject is considered incompatible with most other actions:
For Cyrus, the list is :FILEINTO_KEEP_REDIRECT_REJECT_VACATION_SETFLAG_ADDFLAG_REMOVEFLAG__MARK_UNMARK); refuse should be consistent. (I actually think reject should be considered compatible though! What if I want to log rejected email? As a user, I can't!)

The spamtest and virustest extensions SHOULD be supported.

Specifying response codes (4xx, 5xx, 4.x.x, etc)

Refused emails are refused with a response code of 550.

This is a really messy topic. Should we allow the user to specify the response code? Should they be able to select just one of a set of standard codes? Or should they have no choice? RFC2821, an Internet Standard, says a 550 is appropriate in response to DATA, but in one part frets about 550 as a response code when there are multiple recipients, a case that is dealt with in the security portion of this document.
550 and 552 are common responses, but 552 is not appropriate per RFC2821.
As originally conceived, 'refuse' is only for use with email identified as spam or virus-infested, however users may wish to refuse mail for other reasons, such as a wish to only accept encrypted email. Although concievably not all possible reasons may fall under the umbrella of 550, the KISS principle suggests that it's good enough.

There does not seem to be an RFC that specifies the way for extended status codes of RFC1893 to be provided during an SMTP session. It seems that RFC1891 codes are only for use in emailed DSNs, not as SMTP reply codes. I haven't heard of a usage such as "550 5.7.0 SpamAssassin thinks the message is spam." RFC1891 specifies a way for RFC1894-compliant DSN emails using extended status codes of RFC1893 to be requested during an SMTP session, but it does NOT specify a way for them to be used during the SMTP session itself.
RFC1893 specifies the extended codes, but not where/how they should be used.
It also doesn't specify codes that seem well well suited to the case of email unwanted by the recipient. The only one the makes sense (and only for a small subset of email one might want refused) is 5.6.x for unwanted HTML email. Email from IPs in blocklists, or that has failed a virus-detection, Bayesian or DCC type test doesn't fit well in any category. 5.7.0 ("undefined security status") is the best fit. Again, the KISS principle suggests that a fixed code of 550 is good enough.

SMTP command replies containing response codes can be multi-line, per RFC2821, p.44.

2 Conventions Used in This Document Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS].
This document does not attempt to define what exactly constitutes a spam or virus containing email or how it should be identified, or
   what actions should be taken when detected.
3 SIEVE Extensions 3.1 General Considerations The "refuse" action described below ... 3.2 Test spamtest Syntax: refuse <reason: string> In the following script, messages that test highly positive for spam are refused.

   if spamtest :value "ge" :comparator "i;ascii-numeric" "6" {
               refuse text:
        5.7.0 SpamAssassin thinks the message is spam.
    It is therefore being refused.
        Please call 1-900-PAY-US if you want to reach us.
; elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" {
               fileinto "Suspect";

   SIEVE implementations that implement the "refuse" action have an
   identifier of "refuse" for use with the capability mechanism.
4 Security Considerations SIEVE implementations SHOULD ensure that can only occur for messages that have gone through a legitimate spam or virus check process.

Sieve evaluation as typically implemented requires having the entire message on hand. In SMTP this means the only response code that's left is the final one, where the server accepts or rejects the message on behalf of all recipients. This becomes a problem when there are multiple recipients and some reject the message and some do not. In this case, reject MUST cause an MDN (multiple MDNs?) to be sent on behalf of the rejecting recipients. (Idea: allow MTA to tempfail the rejecting recipients and accept the others, until all recipients are rejecting the email; then it can be refused.) Beyond that, the "refuse" extension does not raise
   any security considerations that are not present in the base [SIEVE]
   protocol, and these issues are discussed in [SIEVE].
5 IANA Considerations The following templates specify the IANA registration of the Sieve
   extensions specified in this document:

5.1 spamtest registration
To: iana(_at_)iana(_dot_)org
   Subject: Registration of new Sieve extension

   Capability name: refuse
   Capability keyword: refuse
   Capability arguments: N/A
   Standards Track/IESG-approved experimental RFC number: this RFC
   Person and email address to contact for further information:

   Matthew Elvey
   3042 Sacramento-ietf St Ste 04
   San Francisco, CA


   This information should be added to the list of sieve extensions
   given on
6 References 6.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.
[SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028,
   January 2001.
7 Acknowledgments Thanks to ... for comments and corrections. 8 Author's Addresses Matthew Elvey
   3042 Sacramento-ietf St Ste 04
   San Francisco, CA


9 Intellectual Property Rights Statement

10 Full Copyright Statement