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

"Mark E. Mallett" <mem@mv.mv.com> Fri, 19 August 2005 18:13 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 j7JIDh4l057326; Fri, 19 Aug 2005 11:13:43 -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 j7JIDhXZ057325; Fri, 19 Aug 2005 11:13:43 -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 j7JIDfdn057308 for <ietf-mta-filters@imc.org>; Fri, 19 Aug 2005 11:13:42 -0700 (PDT) (envelope-from mem@mv.mv.com)
Received: (qmail 35566 invoked by uid 101); 19 Aug 2005 14:13:41 -0400
From: "Mark E. Mallett" <mem@mv.mv.com>
Date: Fri, 19 Aug 2005 14:13:41 -0400
To: Matthew Elvey <matthew@elvey.com>
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, "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
Message-ID: <20050819181341.GC17079@osmium.mv.net>
References: <FF47B65677F611C47F8FC103@ninevah.cyrusoft.com> <20050818190929.GM21465@osmium.mv.net> <4305B817.9070503@isode.com> <43060431.2020702@elvey.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <43060431.2020702@elvey.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>

On Fri, Aug 19, 2005 at 09:09:21AM -0700, Matthew Elvey wrote:
> I think we may need to refer to the fact that what we're concerned about 
> is that if there's an SMTP connection over the open Internet, it is the 
> one where we require the rejection to take place.

   ...

>  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 on the other side of every SMTP connection 
> over the open Internet over which mail is received.
> 
> "on the other side of every SMTP connection over the open Internet" is 
> intended to make clear that the 550 goes to the generally distant, 
> untrusted client.

I snipped a bunch, hope that's OK, because I only wanted to remark on
the "over the open internet" part.  I don't think it's important what
the medium/network/what-have-you is, it's important that the result be
given to the originating client, probably via SMTP.  I'd even go so far
as to say that "refuse" should apply to any protocol where messages are
transported, and that SMTP is being used in the document as an example
protocol, even though it's the example that applies to the vast majority
of probable implementations.  But perhaps you can only carry
non-specificness so far.

mm