Subject: I-D ACTION:draft-ietf-sieve-refuse-reject-05.txt

From: [email-masked]
Date: Fri, 05 Oct 2007 13:15:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering: Reject Extension
	Author(s)	: M. Elvey, et al.
	Filename	: draft-ietf-sieve-refuse-reject-05.txt
	Pages		: 0
	Date		: 2007-10-5
	
This memo updates the definition of the Sieve mail filtering language
   (RFC draft-ietf-sieve-3028bis-XX.txt) "reject" extension, originally
   defined in RFC 3028.
   
   A "Joe-job" is a spam run forged to appear as though it came from an
   innocent party, who is then generally flooded by automated bounces,
   Message Disposition Notifications (MDNs), and personal messages with
   complaints.  The original Sieve "reject" action defined in RFC 3028
   required use of MDNs for rejecting messages, thus contributing to the
   flood of Joe-job spam to victims of Joe-jobs.
   
   This memo updates the definition of the "reject" action to allow
   messages to be refused during the SMTP transaction, and defines the
   "ereject" action to require messages to be refused during the SMTP
   transaction.

   The "ereject" action is intended to replace the "reject" action
   wherever possible.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sieve-refuse-reject-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-refuse-reject-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Dilyan Palauzov <[email-masked]>
Date: Sat, 06 Oct 2007 14:14:42 +0200

Hello

I am reading currently draft-ietf-sieve-refuse-reject-05 and want to say 
some things:
    If action reject shall be allowed only once and if it shall not 
permit the execution of vacation, why doesn't reject imply action "stop"?

    More important, I do not get why a user needs both ereject and 
reject . If she wants to refuse delivery, she needs one action and how 
is it implemented (MDN, smtp 5xx) on the current protocol, does not 
matter for her. My suggestion is to unify both reject and ereject in 
reject, doing 5xx-reject when possible, otherwise something else. Near 
LMTP and SMTP with one recipient, the 5xx reject can be applied in SMTP 
with PRDR enabled 
(http://www.ehsco.com/misc/I-Ds/draft-hall-prdr-00.txt). If the 
environment is SMTP without PRDR, there are still some possibilities:
    - accept the mail for the first recipient and all other recipients 
that have the same script as the first one.  Do temporary reject for all 
other recipients. In this way the DATA-dot-response will be the answer 
for all accepted recipients. In fact, the implementation can deliver 
promptly the mails, save the performed action per recipient and 
Message-ID and the next time it is contacted to receive the mails, that 
were temporary rejected the first time, the implementation reports to 
the connecting MTA if it is going to accept the first-recipient, but 
does not deliver again the mail. The only drawback is, that after 24 
hours or 4 days or whatever the sender might be notified that her mail 
was not delivered yet.
    - accept all mail and generate bounces for the undelivered one

    If an implementation supports both options, then it is up to the 
site administrator to choose which of both policy will be applied - in 
some cases bounces might be totally unacceptable and so on. This 
adjustment is necessary side-wide and I do not think it needs to be 
specified in the sieve-script.

    Unicode issues: if there will be bounces, then Unicode is not a 
problem. If there will be 5xx reject, then ... either the implementation 
transliterates the text to ASCII, or the user are given two options to 
the reject action, the second optional one giving the reason in ascii 
text and applied during smtp negotiations.

    All in all, I think the users need one action to refuse a mail, how 
the refusal works is up to the implementation.

    Greetings,
       Dilian

---

From: Ned Freed <[email-masked]>
Date: Sat, 06 Oct 2007 07:55:26 -0700 (PDT)

> permit the execution of vacation, why doesn't reject imply action "stop"?

Because the future is unpredictable. Even assuming there's no other action
that's compatible with reject currently (I haven't done any sort of check on
this) that does not mean nothing like that will ever be defined. For that
matter, while the current notify draft doesn't appear to say whether or not it
is compatible with reject, I think a case can be made for allowing it.

More generally, it fairly important that we keep the number of "control"
actions, that is, actions that affect the control flow of scripts, to a minimum
in order to facilitate script analysis.

> reject, doing 5xx-reject when possible, otherwise something else.

We've been back and forth over this a lot of times and I do not propose to
repeat those arguments. I suggest you read the list archives to see how/why
we've gotten where we are on this.

I will also add that I personally have no real preferences about any of this. I
simply want a specification I can implement without a lot of trouble. The
current reject/ereject specification looks fairly reasonable to me - my one
quibble is where it says that when UTF-8 Is downgraded to US-ASCII in order to
respond at the  SMTP level the user SHOULD be informed. Short of sending the
user a message sauing that this has been done I have no idea how to do that and
I really don't think users will appreciate getting such messages notifying them
of how rejected mail is handled.

> Near
> (http://www.ehsco.com/misc/I-Ds/draft-hall-prdr-00.txt).

A draft which was fairly controversial when it came out, hasn't been discussed
in months AFAIK and is now expired. The odds of this making to an RFC don't
look all that good. And adding support for this to an MTA isn't exactly
trivial, especially on the server side (lack of per-recipient error tracking
and associated code paths). So I'm not optimistic that even if it were
standardized that we'd see significant deployment at all soon.

> If the
> other recipients.

Which can lead to significant delays in message transfer.

> In this way the DATA-dot-response will be the answer

Couple of big problems here. First, since the message-id isn't available before
the message data is transferred you cannot tell which message you're dealing
with until the message body is tranferred, so the second time you still have to
do the "temporary reject all but one" trick. Then you can check and if you've
already figured out the result for this recipient you can then say yes or no.
But this means the message ends up getting transferred once per recipient. You
may have delivered the message to all recipients in a timely way, but you have
lied and said you haven't. This can easily devolve into a situation where the
originatore gets told there's a problem delivering even though the message has
been delivered. And that's really not acceptable.

Additionally, using the message-id as a unique identifier is nowhere near good
enough. It is unfortunately the case that different messages routinely end up
having the same message-id. They don't usually differ by much, but they do
differ and it is important that such duplicates not be eliminated. So in order
for this approach to work you have to compute a hash over the entire message.
And that's actually surprisingly expensive - this is something we have a lot of
experienc with because we do it sometimes for other reasons.

Now, you could try using ENVID instead of message-id if the DSN extension is
being used. This reduces the number of times the message is transferred to at
most two. But once again you're relying on a single identifier - a much more
reliably unique one but still possibly associated with different messages - and
DSN support is unfortunately not really ubiquitous enough.

> specified in the sieve-script.

This is now doing nothing but rehashing past discussions. I suggest you read
the archives.

> the refusal works is up to the implementation.

Been there, didn't reach consensus on that.

				Ned

---

From: Aaron Stone <[email-masked]>
Date: Sat, 06 Oct 2007 13:32:25 -0700

On Sat, 2007-10-06 at 07:55 -0700, Ned Freed wrote:

[snip all but this item]

> of how rejected mail is handled.

Agreed. For a while I had a very nice error report that read:

    Your script encountered a message that could not be parsed,
    and delivered the message to your Inbox.

This was a _very stupid idea_ -- it basically amplified spam. I suspect
the same scenario here.

I'll drop this text unless someone really wants to keep it.

Aaron

---

From: Aaron Stone <[email-masked]>
Date: Sat, 06 Oct 2007 13:24:40 -0700

Allow me to begin my reply by saying that I've taken on editorship of
this document with the goal of publishing an RFC. The details are not
particularly important to me; for every option there are good arguments.
I'm focusing on making sure that the document itself presents a coherent
set of actions and that it is reasonably well written.

That said...

> permit the execution of vacation, why doesn't reject imply action "stop"?

Section 3.3 says, 

   It is NOT RECOMMENDED that implementations permit the use of
   "reject" with actions that cause mail delivery, such as "keep",
   "fileinto", "redirect".

There are some circumstances where you might want to write a script like
this:

    if whatever {
        ereject "No thanks. But I'm keeping this anyways...";
        fileinto "No Thanks";
    }

IMHO, it would violate the principle of least surprise if the fileinto
failed to execute because ereject had an implicit stop.

> specified in the sieve-script.

This has gone back and forth several times. Have you looked back on the
mailing list archives? There are good arguments both ways...

With respect to PRDR, I suspect that our references to the ability of
LMTP to reject messages on a per-recipient basis could be applied to
this new SMTP extensions without a specific reference in this document.

> text and applied during smtp negotiations.

There were a number of people who disagreed strongly with changing the
rejection text without some authorization from the user.

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 07 Oct 2007 14:31:00 -0400

Hi,
Co-chair hat on:

> set of actions and that it is reasonably well written.

Just to re-iterate - the draft Aaron has produced represents working group 
consensus from the last time this document was thoroughly discussed. 
Certainly the issue of one vs two actions has been discussed to death and 
at this point I consider that issue closed - we are going with two actions. 
The mailing list and IETF meeting minutes contain the full record of all 
these discussions.

That said, the chairs consider finishing this document a priority - so I 
would encourage everyone to please review it. If there are minor issues we 
will ask Aaron to produce an updated version and at that point we will do a 
working group last call on it. We would like to have this document to the 
IESG well before the December meeting.

-- 
Cyrus Daboo