Subject: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h

From: "Matthew Elvey (FM)" <[email-masked]>
Date: Thu, 12 Feb 2004 11:59:59 -0800

Hello, folks.  Please review and provide feedback on the "refuse" 
extension, designed to mostly replace Sieve's "reject" command.

It's been accepted as an I-D (-00), but we've made some further changes 
to what's published, so please review and comment on what's at
<http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt>

We welcome feedback, particularly
  -   changes that include replacement text or
  -   suggestions from Sieve implementers.

Abstract
  
   With "refuse", Sieve gains the ability to simply not accept an
   email during the SMTP transaction (instead of accepting it and then
   sending an MDN [MDN] back to the alleged sender using "reject").
   A Joe-job is a spam run forged to appear as though it came from an
   innocent party, who is then generally flooded by the bounces, MDNs
   and messages with complaints.  With "reject", MDNs contribute to
   the flood of Joe-job spam to victims of Joe-jobs; SMTP level
   refusals usually don't.  So "refuse" provides users the latter
   method to handle unwanted email.

The further changes were limited to Section 13 'Open Issues for 
Discussion' and a typo.

-Matthew & Alexey

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 13 Feb 2004 11:28:09 +0100

Matthew Elvey (FM) writes:
> http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt

I suggest adding a sentence saying that SMTP refusal may happen at the 
RCPT TO or DATA stages, depending on what's convenient to the 
implementation. (I suppose it might also happen at the MAIL FROM stage, 
if a systemwide sieve does the refusal.)

The 550 result code is a fine thing, but shouldn't you also specify an 
extended result code (1893/2034)? 5.7.1, perhaps?

Arnt

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 13 Feb 2004 10:37:30 -0500

Hi Arnt,

--On Friday, February 13, 2004 11:28 AM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

| I suggest adding a sentence saying that SMTP refusal may happen at the
| RCPT TO or DATA stages, depending on what's convenient to the
| implementation. (I suppose it might also happen at the MAIL FROM stage,
| if a systemwide sieve does the refusal.)

But SIEVE has to operate on the message data - there isn't enough 
information before the DATA command to run SIEVE, unless you extend SIEVE 
with tests for SMTP-Envelope data (e.g. a MAIL FROM test). Frankly any 
system-wide script like that is better left to the SMTP implentation's own 
filtering/ruleset behaviour.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 13 Feb 2004 16:47:14 +0100

Cyrus Daboo writes:
> information before the DATA command to run SIEVE, unless you extend 
> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test).

As I remember the draft I read, a spamtest implementation can legally 
arrive at a conclusion without considering the body, so if the script's 
first rule is a spam test, the body need not be considered. (I agree 
that the body will almost always be considered.)

Anyway, I think the possibility of e.g. a future MAIL FROM test is 
reason enough to _permit_ the refusal to happen at any stage of the 
SMTP/LTMP process.

> Frankly any system-wide script like that is better left to the SMTP 
> implentation's own filtering/ruleset behaviour.

Sure, but that own filtering behaviour might just be sieve ;)

Arnt

---

From: Tony Finch <[email-masked]>
Date: Fri, 13 Feb 2004 16:01:25 +0000

>reason enough to _permit_ the refusal to happen at any stage of the 

There's already an envelope from test in RFC 3028.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
CROMARTY FORTH TYNE DOGGER: WESTERLY VEERING NORTHERLY 3 OR 4. OCCASIONAL
RAIN. MODERATE OR GOOD, OCCASIONALLY POOR IN DOGGER.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 13 Feb 2004 10:59:01 -0500

Hi Matthew,

--On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey (FM)" 
<[email-masked]> wrote:

| Hello, folks.  Please review and provide feedback on the "refuse"
| extension, designed to mostly replace Sieve's "reject" command.

Question - is there any situation where you would want both reject and 
refuse available at the same time? i.e. couldn't we just get away with an 
extension that simply indicates that the existing reject command will 
actually run during the SMTP transaction and will generate an SMTP error 
instead of an MDN? Or, if modifying the base-spec reject behaviour is 
really not allowed in this way, how about having refuse do either SMTP 
error or MDN as appropriate for the system? That would mean that users can 
write one script using a single command and have it work on any SIEVE 
system, whether SIEVE runs at SMTP time or post-SMTP. I would hate to have 
to change reject<->refuse every time I moved or copied a script across 
different systems.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 13 Feb 2004 11:10:27 -0500

Hi Arnt,

--On Friday, February 13, 2004 4:47 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

|> But SIEVE has to operate on the message data - there isn't enough
|> information before the DATA command to run SIEVE, unless you extend
|> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test).
|
| As I remember the draft I read, a spamtest implementation can legally
| arrive at a conclusion without considering the body, so if the script's
| first rule is a spam test, the body need not be considered. (I agree that
| the body will almost always be considered.)
|
| Anyway, I think the possibility of e.g. a future MAIL FROM test is reason
| enough to _permit_ the refusal to happen at any stage of the SMTP/LTMP
| process.

If you are going to run a script before DATA then you are going to have to 
limit the set of available sieve tests to just those that make sense - in 
other words you need to define different 'profiles' of the sieve syntax 
that are valid for different phases of the message delivery process. I 
think it would be a mistake just to say that certain tests (e.g. for header 
addresses) become no-ops when run before DATA. As such I think that a 
document that defines such a profile would allow the refusal on MAIL FROM 
or RCPT TO without needing to define that in refuse.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Feb 2004 16:55:42 +0000

Arnt Gulbrandsen wrote:

> arrive at a conclusion without considering the body, so if the 
> script's first rule is a spam test, the body need not be considered. 
> (I agree that the body will almost always be considered.)

In theory any Sieve script that doesn't test message headers/body can be 
executed before DATA command.
But the task of checking if a Sieve script doesn't require message 
content might not be a trivial task. Especially if the Sieve engine also 
supports variables.

So I would rather ignore the issue of executing Sieve scripts before 
DATA command in the Sieve "refuse" extension.

> Sure, but that own filtering behaviour might just be sieve ;)

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Feb 2004 16:59:34 +0000

Arnt Gulbrandsen wrote:

> implementation. (I suppose it might also happen at the MAIL FROM 
> stage, if a systemwide sieve does the refusal.)
>

This is an open issue in the document ;-). Matthew and I weren't sure 
what to do with enhanced status codes.
Do you suggest that we mandate 5.7.1 or should we instead mention it and 
allow an MTA to select another enhanced status code if appropriate?

Alexey

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 13 Feb 2004 15:29:39 -0500

> to change reject<->refuse every time I moved or copied a script across 

This was my initial reaction too: rather than introduce a new action,
introduce a new "smtp-time" operating mode where the existing "reject"
action would have the desired effect.  One might even add an option
to "reject" to specify the SMTP response code and the extended result code,
which could be used in the smtp-time mode and ignore otherwise.

As I mentioned in another thread, this notion of operating mode could
also be useful in other contexts.

Re the draft text: why is it "test refuse" and not "action refuse" ?

mm