Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt

Matthew Elvey <matthew@elvey.com> Tue, 23 August 2005 19:21 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 j7NJLiCA064065; Tue, 23 Aug 2005 12:21:44 -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 j7NJLitv064064; Tue, 23 Aug 2005 12:21:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NJLhWr064056 for <ietf-mta-filters@imc.org>; Tue, 23 Aug 2005 12:21:44 -0700 (PDT) (envelope-from matthew@elvey.com)
Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 26667CCA1EB; Tue, 23 Aug 2005 15:21:41 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Tue, 23 Aug 2005 15:21:41 -0400
X-Sasl-enc: BrcsVqvc8NASWlJDUxsQtXUf8ESd4Cb3R2t1KC6G+swz 1124824901
Received: from [192.168.2.98] (adsl-67-112-27-89.dsl.snfc21.pacbell.net [67.112.27.89]) by frontend3.messagingengine.com (Postfix) with ESMTP id BAF041E6; Tue, 23 Aug 2005 15:21:40 -0400 (EDT)
Message-ID: <430B7743.5030004@elvey.com>
Date: Tue, 23 Aug 2005 12:21:39 -0700
From: Matthew Elvey <matthew@elvey.com>
User-Agent: Thunderbird 1.0+ (Macintosh/20050811)
MIME-Version: 1.0
To: "Mark E. Mallett" <mem@mv.mv.com>, IETF MTA Filters List <ietf-mta-filters@imc.org>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
References: <FF47B65677F611C47F8FC103@ninevah.cyrusoft.com> <20050818190929.GM21465@osmium.mv.net> <4305B817.9070503@isode.com> <20050819174803.GB17079@osmium.mv.net> <430895AB.1090603@isode.com> <430A2A51.6080103@elvey.com> <20050823180817.GO26861@osmium.mv.net>
In-Reply-To: <20050823180817.GO26861@osmium.mv.net>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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>

On 8/23/05 11:08 AM, Mark E. Mallett sent forth electrons to convey:
> On Mon, Aug 22, 2005 at 12:41:05PM -0700, Matthew Elvey wrote:
>   
>> On 8/21/05 7:54 AM, Alexey Melnikov sent forth electrons to convey:
>>     
>>> right.  the key is that you decline a message which is sent from a
>>> different administrative domain.  [...] a "refuse" MUST be able
>>> to tell the other administrative domain that the message was rejected
>>> without instantiating the sending of a new message.
>>>       
>> How's this replacement?
>>
>> (The first sentence is unchanged.)
>>
>>   The "refuse" action refuses delivery of a message by sending back
>>
>> the 550 SMTP response code to an SMTP client. This extension can be 
>> supported only by a Sieve implementation capable of sending the 550 over 
>> an SMTP connection between Administrative Units.
>>     
>
> Well, I'm probably being anal (again).  To me, the use of "between
> Administrative Units" and "over the open Internet" are birds of a
> feather.  I don't think it's important to specify where the message is
> transported, or between whom-- only that the message is turned away by
> the receiver during transport, thus avoiding a later asynchronous
> notification via a separate email message.  e.g. I think refusal should
> apply to a transmission to the SMTP server running on localhost.
>
> mm
>   
No, that doesn't address my concern from a previous email:

On 8/19/05 2:18 PM, Matthew Elvey sent forth electrons to convey:
> ...[If] a Sieve script running on Dest  encounters a 'refuse', and 
> sends a 550 to Relay 2, if Relay 2 then generates a bounce, instead of 
> sending a 550 to MSA, then Dest MUST NOT be considered compliant with 
> 'refuse'. 
>    +------------+                                    +-----------+
>    | Originator |                                    | Recipient |
>    +-----+------+                                    +-----------+
>          |                                                 ^
>          |                    Internet                     |
>          |                    ___^___                      |
>          V                   /       \                     |
>      +---------+    +--------+       +---------+      +----+----+
>      |         |    |        |       |         |      |         |
>      | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
>      |         |    |        |       |         |      |         |
>      +----+----+    +--------+       +---------+      +---------+
>
>                                  \_________Destination_AU__________/
>
>
That's why we need something like "between Administrative Units" of 
"over the open Internet".