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.
Abstract
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).
Discussion
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.
Example:
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
U.S.A.
<mailto:sieve3(_at_)matthew(_dot_)elvey(_dot_)com>
This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions.
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
U.S.A.
<mailto:sieve3(_at_)matthew(_dot_)elvey(_dot_)com>
9 Intellectual Property Rights Statement
<boilerplate>
10 Full Copyright Statement
<boilerplate>