Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
"Mark E. Mallett" <mem@mv.mv.com> Thu, 18 August 2005 19:09 UTC
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IJ9Ubv053858; Thu, 18 Aug 2005 12:09:30 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IJ9UcY053857; Thu, 18 Aug 2005 12:09:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7IJ9TQc053832 for <ietf-mta-filters@imc.org>; Thu, 18 Aug 2005 12:09:29 -0700 (PDT) (envelope-from mem@mv.mv.com)
Received: (qmail 84523 invoked by uid 101); 18 Aug 2005 15:09:29 -0400
From: "Mark E. Mallett" <mem@mv.mv.com>
Date: Thu, 18 Aug 2005 15:09:29 -0400
To: Cyrus Daboo <daboo@isamet.com>
Cc: IETF MTA Filters List <ietf-mta-filters@imc.org>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Message-ID: <20050818190929.GM21465@osmium.mv.net>
References: <FF47B65677F611C47F8FC103@ninevah.cyrusoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <FF47B65677F611C47F8FC103@ninevah.cyrusoft.com>
User-Agent: Mutt/1.4.2.1i
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>
> 3. Discussion of finer points > > The "refuse" action MUST refuse to accept an email for delivery at > the SMTP/LMTP level by returning a 5XX reply code, instead of > sending an MDN as required by the "reject" action, other than for > the two exceptions specified below. A SIEVE implementation that > cannot do so MUST NOT claim to support the refuse extension. This means that scripts have to be written with awareness of the site's email delivery architecture, and if that architecture changes, all scripts have to change. I think this is a big burden on both script writers and site admins. Even if approach is to have separate "reject" and "refuse" verbs, I'd like to see some way of avoiding this burden. > There is an exception when a message has multiple valid recipients, > and at least one but not all of them are refusing delivery (whether > the refusal is caused by execution of a Sieve "refuse" or for > another reason). In this case, the server MUST accept the message > and generate DSNs for all recipients that are refusing it. I get what this is saying, but I don't think this is said exactly right. An SMTP server can issue 4xx deferal codes for some of the valid recipients. This can be done for various reasons, e.g. if some of the valid recipients are over quota, or if the SMTP server is using a trick to allow it to do post-DATA rejection by only focusing on one recipient at a time (I don't know if anybody actually does this, but I've heard it proposed..). So it's really "when more than one RCPT TO has been accepted" instead of "when a message has multiple valid recipients." (picky, I know.) > 4.2 "reject" compatibility with other actions > Implementations MUST prohibit more than one reject in a SIEVE > script. must prohibit "the execution of..." (certainly more than one reject can appear in a script). > 5.1 Action refuse > The "refuse" action refuses delivery of a message by sending back > the 550 SMTP response code to an SMTP client. > > This extension can be only supported by a Sieve implementation > running in an MTA. The way this is worded, an implementation that communicates with an MTA via LMTP (or any other protocol or mechanism, for that matter) is prohibited from using "refuse." There are multiple ways that an MDA may be invoked by an MTA during the SMTP dialog, where refusal can be communicated back to the SMTP client. The MTA itself isn't necessarily (and probably isn't likely to be) running the Sieve script itself. And actually I am not sure that LMTP needs to be mentioned in the document at all, other than as an example of one of the ways that an MTA and an MDA might communicate during the SMTP dialog. The important thing is that the Sieve script is being run at SMTP time and its results are somehow used by the MTA to respond to the SMTP client. This extension can only be supported by a Sieve implementation that is invoked on behalf of the MTA during SMTP time, and that can communicate its results to the MTA which can then return a status to the SMTP client. Another somewhat thorny point is that a Sieve script may be invoked at the time when the SMTP server sees the "RCPT TO" so that the refusal may be communicated to the SMTP client at that time (before DATA). At this stage, various Sieve facilities (e.g. header tests, fileinto, keep) are not available. I don't know whether this has to be mentioned in this draft, but once you have "refuse" capability, this does come into play. > Example: > require ["refuse", "spamtest"] the missing comparator was already mentioned, but it also needs "fileinto" for the elsif to work. > > if spamtest :value "ge" :comparator "i;ascii-numeric" "6" { > refuse text: > SpamAssassin thinks the message is spam. > It is therefore being refused. > Please call 1-900-PAY-US if you want to reach us. > . > ; add "}" here. > elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" { > fileinto "Suspect"; > } Yours, -mm-
- Working Group Last Call for draft-ietf-sieve-refu… Cyrus Daboo
- Re: Working Group Last Call for draft-ietf-sieve-… Michael Haardt
- Re: Working Group Last Call for draft-ietf-sieve-… Alexey Melnikov
- Re: Working Group Last Call for draft-ietf-sieve-… Michael Haardt
- Re: Working Group Last Call for draft-ietf-sieve-… Alexey Melnikov
- Re: Working Group Last Call for draft-ietf-sieve-… Mark E. Mallett
- Re: Working Group Last Call for draft-ietf-sieve-… Mark E. Mallett
- Re: Working Group Last Call for draft-ietf-sieve-… Kjetil Torgrim Homme
- Re: Working Group Last Call for draft-ietf-sieve-… Alexey Melnikov
- Re: Working Group Last Call for draft-ietf-sieve-… Michael Haardt
- Re: Working Group Last Call for draft-ietf-sieve-… Matthew Elvey
- Re: Working Group Last Call for draft-ietf-sieve-… Mark E. Mallett
- Re: Working Group Last Call for draft-ietf-sieve-… Mark E. Mallett
- Re: Working Group Last Call for draft-ietf-sieve-… Matthew Elvey
- Re: Working Group Last Call for draft-ietf-sieve-… Kjetil Torgrim Homme
- Re: Working Group Last Call for draft-ietf-sieve-… Alexey Melnikov
- Re: Working Group Last Call for draft-ietf-sieve-… Matthew Elvey
- Re: Working Group Last Call for draft-ietf-sieve-… Mark E. Mallett
- Re: Working Group Last Call for draft-ietf-sieve-… Kjetil Torgrim Homme
- Re: Working Group Last Call for draft-ietf-sieve-… Mark E. Mallett
- Re: Working Group Last Call for draft-ietf-sieve-… Matthew Elvey
- Re: Working Group Last Call for draft-ietf-sieve-… Mark E. Mallett
- Re: Working Group Last Call for draft-ietf-sieve-… Matthew Elvey
- Re: Working Group Last Call for draft-ietf-sieve-… Kjetil Torgrim Homme
- Re: Working Group Last Call for draft-ietf-sieve-… Matthew Elvey
- Re: Working Group Last Call for draft-ietf-sieve-… Kjetil Torgrim Homme
- Re: Working Group Last Call for draft-ietf-sieve-… Mark E. Mallett