Re: Treat as a WGLC: draft-martin-managesieve-10.txt

[Alexey Melnikov <[e-mail]>]

Stephan Bosch wrote:

>Hi Alexey,
>  
>
Hi Stephan,

>Alexey Melnikov wrote:
>  
>
>>I've submitted version 10 of the ManageSieve draft. I believe it
>>addresses all major issues with the document. I would like to request
>>publication of this document shortly.
>>
>>Because Sieve WG hasn't rechartered yet, I can't request a formal WGLC
>>on the document. However I would like to ask people to treat my
>>request as a WGLC.
>>Please send me your comments by July 7th.
>>    
>>
>I've quickly scanned through the new document and the way the '+' issue
>is resolved for the string literals worries me. If I am not mistaken,
>the new specification requires the '+' from the client and prohibits it
>from the server. If I remember correctly, the '+' was required both ways
>in old versions of this draft and you decided to remove it to make
>things more logical compared to the similar IMAP string literal and to
>match the existing timsieved implementation.
>
Yes.

>I thought the idea was to simply allow and ignore the '+' for legacy implementations.
>
ManageSieve was largely documenting Cyrus timsieved and timsieved never 
emitted "+" to clients.
If you know any server that emits non-synchronizing literals to clients, 
please let me know. But absent any evidence that this would break 
deployed servers, I would prefer to keep consistency with IMAP and 
timsieved.

>Strictly requiring it from clients seems cumbersome and will, to my opinion,
>likely introduce even more incompatibilities.
>  
>
As far as I know ManageSieve never allowed clients to send synchronizing 
literals (literals without +). timsieved allows for that (because it 
reuses IMAP parser), but I don't think it ever emits IMAP style "+ go 
ahead" back to clients. So it is not consistent with IMAP either.

If people think that support for synchronizing literals in the direction 
from the client to the server is needed, I can add that. But I am not 
convinced that this is a problem either.

>Is there a specific reason to implement it this way? Sorry that I missed
>version 09 of this document, but I did not actively check for new
>versions and I didn't see it posted on this list.
>
>I do like the new extensions you introduced. :) I'll thoroughly read the
>new document in a few days to update my ManageSieve implementation.
>  
>
Sounds good to me :-).




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5TI0XBX043810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jun 2008 11:00:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5TI0XPw043809; Sun, 29 Jun 2008 11:00:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5TI0VFl043803 for <[e-mail]>; Sun, 29 Jun 2008 11:00:32 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.173] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 29 Jun 2008 19:00:30 +0100
Message-ID: <[e-mail]>
Date: Sun, 29 Jun 2008 19:00:22 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Stephan Bosch <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephan Bosch wrote:

>Hi Alexey,
>  
>
Hi Stephan,

>Alexey Melnikov wrote:
>  
>
>>I've submitted version 10 of the ManageSieve draft. I believe it
>>addresses all major issues with the document. I would like to request
>>publication of this document shortly.
>>
>>Because Sieve WG hasn't rechartered yet, I can't request a formal WGLC
>>on the document. However I would like to ask people to treat my
>>request as a WGLC.
>>Please send me your comments by July 7th.
>>    
>>
>I've quickly scanned through the new document and the way the '+' issue
>is resolved for the string literals worries me. If I am not mistaken,
>the new specification requires the '+' from the client and prohibits it
>from the server. If I remember correctly, the '+' was required both ways
>in old versions of this draft and you decided to remove it to make
>things more logical compared to the similar IMAP string literal and to
>match the existing timsieved implementation.
>
Yes.

>I thought the idea was to simply allow and ignore the '+' for legacy implementations.
>
ManageSieve was largely documenting Cyrus timsieved and timsieved never 
emitted "+" to clients.
If you know any server that emits non-synchronizing literals to clients, 
please let me know. But absent any evidence that this would break 
deployed servers, I would prefer to keep consistency with IMAP and 
timsieved.

>Strictly requiring it from clients seems cumbersome and will, to my opinion,
>likely introduce even more incompatibilities.
>  
>
As far as I know ManageSieve never allowed clients to send synchronizing 
literals (literals without +). timsieved allows for that (because it 
reuses IMAP parser), but I don't think it ever emits IMAP style "+ go 
ahead" back to clients. So it is not consistent with IMAP either.

If people think that support for synchronizing literals in the direction 
from the client to the server is needed, I can add that. But I am not 
convinced that this is a problem either.

>Is there a specific reason to implement it this way? Sorry that I missed
>version 09 of this document, but I did not actively check for new
>versions and I didn't see it posted on this list.
>
>I do like the new extensions you introduced. :) I'll thoroughly read the
>new document in a few days to update my ManageSieve implementation.
>  
>
Sounds good to me :-).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5SKOq73072272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2008 13:24:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5SKOq6E072271; Sat, 28 Jun 2008 13:24:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5SKOmNb072261 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 28 Jun 2008 13:24:51 -0700 (MST) (envelope-from [e-mail])
Received: from ip565f7a5d.direct-adsl.nl ([86.95.122.93] helo=[192.168.1.72]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1KCfua-0001UZ-RJ; Sat, 28 Jun 2008 21:16:40 +0200
Message-ID: <[e-mail]>
Date: Sat, 28 Jun 2008 22:24:19 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-VirusScan: Found to be clean
X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.999, required 5, autolearn=not spam, ALL_TRUSTED -0.40, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: [e-mail]
X-Spam-Status: No
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Alexey,

Alexey Melnikov wrote:
> I've submitted version 10 of the ManageSieve draft. I believe it
> addresses all major issues with the document. I would like to request
> publication of this document shortly.
>
> Because Sieve WG hasn't rechartered yet, I can't request a formal WGLC
> on the document. However I would like to ask people to treat my
> request as a WGLC.
> Please send me your comments by July 7th.
I've quickly scanned through the new document and the way the '+' issue
is resolved for the string literals worries me. If I am not mistaken,
the new specification requires the '+' from the client and prohibits it
from the server. If I remember correctly, the '+' was required both ways
in old versions of this draft and you decided to remove it to make
things more logical compared to the similar IMAP string literal and to
match the existing timsieved implementation. I thought the idea was to
simply allow and ignore the '+' for legacy implementations. Strictly
requiring it from clients seems cumbersome and will, to my opinion,
likely introduce even more incompatibilities.

Is there a specific reason to implement it this way? Sorry that I missed
version 09 of this document, but I did not actively check for new
versions and I didn't see it posted on this list.

I do like the new extensions you introduced. :) I'll thoroughly read the
new document in a few days to update my ManageSieve implementation.

Regards,

--
Stephan Bosch
[e-mail]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5PFJBVP051527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 08:19:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5PFJBUb051526; Wed, 25 Jun 2008 08:19:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5PFJA7X051508 for <[e-mail]>; Wed, 25 Jun 2008 08:19:11 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.191] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 25 Jun 2008 16:19:08 +0100
Message-ID: <[e-mail]>
Date: Wed, 25 Jun 2008 16:18:50 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Status of the Sieve WG drafts
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A quick reminder/update on what is happening to various WG drafts:

1). draft-ietf-sieve-refuse-reject-07.txt - Cyrus will be sending 
publication request to Lisa shortly
2). draft-ietf-sieve-mime-loop-04.txt - I am waiting for authors to 
update the document.
3). draft-ietf-sieve-editheader-11.txt - I am discussing text to address 
Pasi Eronen's DISCUSS on security considerations section. See 
<https://datatracker.ietf.org/idtracker/ballot/2770/> for more details.
4). draft-ietf-sieve-notify-mailto-07.txt - waiting for authors to 
update the document to address post-IETF-LC issues. I've added the list 
of issues to trac hosted on tools.ietf.org: 
<http://tools.ietf.org/wg/sieve/trac/query?status=new&status=assigned&status=reopened&component=notify-mailto>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5MERxQ7087025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 07:27:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5MERx8w087024; Sun, 22 Jun 2008 07:27:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5MERvB4087015 for <[e-mail]>; Sun, 22 Jun 2008 07:27:58 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.2] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 22 Jun 2008 15:27:56 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Sun, 22 Jun 2008 15:27:53 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Treat as a WGLC: draft-martin-managesieve-10.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title           : A Protocol for Remotely Managing Sieve Scripts
>	Author(s)       : A. Melnikov, T. Martin
>	Filename        : draft-martin-managesieve-10.txt
>	Pages           : 34
>	Date            : 2008-06-21
>
>Sieve scripts allow users to filter incoming email.  Message stores
>are commonly sealed servers so users cannot log into them, yet users
>must be able to update their scripts on them.  This document
>describes a protocol "ManageSieve" for securely managing Sieve
>scripts on a remote server.  This protocol allows a user to have
>multiple scripts, and also alerts a user to syntactically flawed
>scripts.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-martin-managesieve-10.txt
>  
>
I've submitted version 10 of the ManageSieve draft. I believe it 
addresses all major issues with the document. I would like to request 
publication of this document shortly.

Because Sieve WG hasn't rechartered yet, I can't request a formal WGLC 
on the document. However I would like to ask people to treat my request 
as a WGLC.
Please send me your comments by July 7th.

Thank you,
Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KEDNRS050775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 07:13:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5KEDNEv050774; Fri, 20 Jun 2008 07:13:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (daboo.name [151.201.22.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KEDLtk050732 for <[e-mail]>; Fri, 20 Jun 2008 07:13:22 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6D4D490C506; Fri, 20 Jun 2008 10:13:20 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLGasih2ZG3Y; Fri, 20 Jun 2008 10:13:20 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 8347D90C4FF; Fri, 20 Jun 2008 10:13:19 -0400 (EDT)
Date: Fri, 20 Jun 2008 10:13:16 -0400
From: Cyrus Daboo <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,

--On June 20, 2008 12:15:35 PM +0200 Arnt Gulbrandsen 
<[e-mail]> wrote:

> Please let's have this sieve extension published as an RFC. It's good.
> Exactly how good it is in practice is a QoS matter, not a sieve standards
> matter.

As co-chair I am going to declare that we have WG consensus on the current 
draft, in spite of Matthew's comments. I don't see anyone else agreeing 
whole heartedly with his position. Therefore we are going to move ahead 
with submitting this draft to the IESG next week for IETF last call and 
IESG review.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KAHEB5037530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 03:17:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5KAHEdv037529; Fri, 20 Jun 2008 03:17:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KAHCAs037513 for <[e-mail]>; Fri, 20 Jun 2008 03:17:13 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 015074AC5A for <[e-mail]>; Fri, 20 Jun 2008 12:17:18 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1213957038-5025-1792; Fri, 20 Jun 2008 12:17:18 +0200
Message-Id: <[e-mail]>
Date: Fri, 20 Jun 2008 12:15:35 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme writes:
> On Thu, 2008-06-19 at 12:43 -0700, Matthew Elvey wrote:
>> I believe all or at least nearly all multi-component implementations 
>> can and should work this way.
>
> I'm not aware of any open source systems where this is possible, so 
> please enlighten me.

I think it can be done with Postfix, but it's far from easy. Needs a bit 
of programming.

IMO the idea of demanding this kind of cooperation is overreach. It's 
not acceptable for a sieve extension to reach out beyond LMTP and make 
demands of the program that connects to the MDA via LMTP.

Please let's have this sieve extension published as an RFC. It's good. 
Exactly how good it is in practice is a QoS matter, not a sieve 
standards matter.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5K8kv0e095364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 01:46:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5K8kvIl095363; Fri, 20 Jun 2008 01:46:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5K8krbB095343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 20 Jun 2008 01:46:56 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1K9cGi-0001vv-SR; Fri, 20 Jun 2008 10:46:52 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx4.uio.no) by mail-mx4.uio.no with esmtp  (Exim 4.67) (envelope-from <[e-mail]>) id 1K9cGi-0002NF-Me; Fri, 20 Jun 2008 10:46:52 +0200
Received: from feh.linpro.no ([87.238.42.45]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user kjetilho (Exim 4.67) (envelope-from <[e-mail]>) id 1K9cGi-0002NA-L3; Fri, 20 Jun 2008 10:46:52 +0200
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
From: Kjetil Torgrim Homme <[e-mail]>
Reply-To: [e-mail]
To: Matthew Elvey <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Fri, 20 Jun 2008 10:46:51 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: BBDB5804D68ED0CE8FE6E7FC42A16E2A66348FD8
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 615 total 8996338 max/h 8345 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2008-06-19 at 12:43 -0700, Matthew Elvey wrote:
> This is how a conforming system implementation would work:
> 
> Step 1) SMTP client connects to receiving system, which consists of an 
> ingress MTA sitting on the Internet  in front of (and protecting) an MDA 
> (store) with which it communicates over LMTP.  The system (the MDA in 
> particular) contains and processes Sieve scripts.
>
> Step 2) SMTP client continues the SMTP conversation to the point that 
> the system receives a message to one recipient and the character 
> sequence "<CRLF>.<CRLF>".  (See 4.1.1.4 DATA (DATA) of RFC 2821)

"one recipient".  check.  do you have a document where best practice for
ensuring this is documented?  (please don't say "Everyone switch to
Qmail" :-)

> Step 3) The system does NOT need to IMMEDIATELY reply,  instead, it may 
> perform some processing, as RFC 2821 indicates.  RFC 2821 says 
> specifically that the SMTP client SHOULD wait a minimum of at least 10 
> minutes for the "250 OK" reply.  This processing should include:
> 
> Step 4) The MTA immediately connects to the MDA and attempts to pass on 
> the message. If the MDA decides to 'ereject' the message, the MTA will 
> pass along the message to the SMTP client by sending a failure message, 
> instead of "250 OK".
> 
> I believe all or at least nearly all multi-component implementations can 
> and should work this way.

I'm not aware of any open source systems where this is possible, so
please enlighten me.  I was going to extend Exim's callout mechanism to
do a full body callout so that it could be combined with Cyrus' LMTP,
but didn't get that far before switching to non-mail related employment.

-- 
regards,
Kjetil T.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JJhOhl036480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2008 12:43:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5JJhNaE036479; Thu, 19 Jun 2008 12:43:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JJhMJS036471 for <[e-mail]>; Thu, 19 Jun 2008 12:43:22 -0700 (MST) (envelope-from [e-mail])
Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id D7CA8127B00; Thu, 19 Jun 2008 15:43:21 -0400 (EDT)
Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 19 Jun 2008 15:43:21 -0400
X-Sasl-enc: bUKqejyZ7jL8m/L7ficUfUIZRCq1R2tWS7qr3/sQhWQg 1213904601
Received: from [192.168.18.136] (c-67-169-60-252.hsd1.ca.comcast.net [67.169.60.252]) by mail.messagingengine.com (Postfix) with ESMTPSA id 166492DE9D; Thu, 19 Jun 2008 15:43:20 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Jun 2008 12:43:19 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 3.0a1 (Macintosh/2008050714)
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is how a conforming system implementation would work:

Step 1) SMTP client connects to receiving system, which consists of an 
ingress MTA sitting on the Internet  in front of (and protecting) an MDA 
(store) with which it communicates over LMTP.  The system (the MDA in 
particular) contains and processes Sieve scripts.

Step 2) SMTP client continues the SMTP conversation to the point that 
the system receives a message to one recipient and the character 
sequence "<CRLF>.<CRLF>".  (See 4.1.1.4 DATA (DATA) of RFC 2821)

Step 3) The system does NOT need to IMMEDIATELY reply,  instead, it may 
perform some processing, as RFC 2821 indicates.  RFC 2821 says 
specifically that the SMTP client SHOULD wait a minimum of at least 10 
minutes for the "250 OK" reply.  This processing should include:

Step 4) The MTA immediately connects to the MDA and attempts to pass on 
the message. If the MDA decides to 'ereject' the message, the MTA will 
pass along the message to the SMTP client by sending a failure message, 
instead of "250 OK".

I believe all or at least nearly all multi-component implementations can 
and should work this way.

Note: if the MTA tries to contact the MDA in step 4 and is unsuccessful, 
it can try again several times; it should have at least 10 minutes 
(that's a lot of milliseconds)  to get back to the SMTP client.   And 
even at that point, it can send a 4xx, and try again when the SMTP 
client tries again.

In other words, a conforming system cannot include an MTA that 
immediately accepts such a message, passes it to an MDA that processes 
it with a sieve script that decides to ereject it, and have that MDA 
blithely send out a DSN.


On 6/18/08 5:21 PM, Ned Freed wrote:
> <did it again.  :( >
>> On 5/29/08 9:22 AM, Ned Freed wrote:
>> > <Ned quote me but didn't include a quotation line; please do so in
>> > future, Ned.>: 
>
>> >> And I'm not clear why this is needed; I don't think it's the case:
>> >> (However, the LMTP client may then have no choice
>> >>     but to generate a DSN to report the error, which may result in
>> >>     blowback.)
>> >> Where it appears to be the case, the LMTP client may just need to be
>> >> fixed.
>> >
>> > Fixed how? Suppose the LMTP client is on an ingress MTA. Messages come
>> > in from the Internet using SMTP and are then sent on using LMTP to 
>> affect
>> > final delivery.
>
>> I suspected you'd be bringing this case up again.
>> It needs to be fixed if it accepts the message before it has determined
>> whether it should receive it.
>
> But that's operating at the SMTP level, not the LMTP level. And the only
> way to enforce that is to not allow LMTP server-side implementation of
> ereject.
>
> But if that's the consensus for what we want to do (and while I 
> personally
> don't object I've seen no consensus for such a change) then we need to 
> come out
> and say that explicitly, not try and eliminate the case by first 
> including LMTP
> as a possible place for ereject to be used but then trying to 
> Venn-diagram it
> out of existance with a bunch of complex overlapping requirements LMTP 
> cannot
> meet.
>
> The approach you're advocating is a sure-fire recipe for confused 
> implementors and broken implementations.
>
>> (This discussion has already been hashed out; it's a bit frustrating to
>> have to go through it again.)
>
> Well, that discussion apparently did not result in even a mention 
> being added
> of the likely consequences of LMTP server-side use of rereject, so 
> apparently
> it didn't stick.
>
>> > Suppose the Sieve implementation is operating as part of the LMTP
>> > server. (This
>> > isn't how I'd ever do it, but it is nevertheless a perfectly 
>> legitimate
>> > implementation option.) A message comes in via SMTP and is queued for
>> > delivery. The LMTP client sends it to the LMTP server, which then runs
>> > the Sieve which then does an ereject. This is then translated into a
>> > 550 LMTP response.
>> >
>> > What is the MTA supposed to do now?
>
>> You're asking me what to do once you've painted yourself into a corner.
>> My answer is: DON'T paint yourself into a corner.
>
> And the only way to avoid the corner (in the ereject case at least) is 
> not
> to operate at the LMTP server level.
Nope; see the 4 steps above.
>
> More generally, however, there's no way to avoid this case. We go to a 
> lot of
> trouble to try and detect things like over quota conditions so we can 
> reject at
> the SMTP level. But this depends on back-channel communication to our 
> MTA from
> our store. If our MTA is used with someone else's LMTP server - as it 
> sometimes
> is - we have no way to perform a useful check at the SMTP level.
If you'd care to explain why an implementation can't conform to the 4 
steps I explain, I'm all ears; I have yet to hear such an explanation.  
(Other than the claim that the system isn't a system; the MTA and MDA 
are independent.)  My response is that if someone insists on looking at 
things that way, that's their right, but then their MDA should not be 
considered conforming.

Again, I've done nothing but argue with you about the difficulty and 
merits of conforming to proposed requirements.  I should expressed that 
differently, and for that I apologize: I could have instead said that 
changing an existing implementation to conform could be difficult and 
time consuming; I have said so before.  I'm sorry that you feel 
attacked, but I have not attacked you.







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5J1gx73067728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 18:42:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5J1gxki067727; Wed, 18 Jun 2008 18:42:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5J1gwt3067715 for <[e-mail]>; Wed, 18 Jun 2008 18:42:59 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 18 Jun 2008 18:42:56 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 18 Jun 2008 18:42:53 -0700 (PDT)
Date: Wed, 18 Jun 2008 17:21:45 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
In-reply-to: "Your message dated Wed, 18 Jun 2008 11:22:11 -0700" <[e-mail]>
To: Matthew Elvey <[e-mail]>
Cc: [e-mail], Ned Freed <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On 5/29/08 9:22 AM, Ned Freed wrote:
> > <Ned quote me but didn't include a quotation line; please do so in
> > future, Ned.>:
> >
> >
> >> I disagree.  There is a loophole for an implementer to decide that
> >> what he or
> >> she feels is preferred is to not bother fulfilling this requirement.
> >> It needs
> >> to be closed.
> >
> > Then you really need to provide better evidence that such a loophole
> > exists -
> > because I'm not seeing it.

> That's funny.  You do see it.  You just don't realize it.  You drove the
> LMTP truck through the loophole!! (see LMTP discussion below)  My latest
> draft doesn't have the loophole that you've insisted LMTP
> implementations should be able to drive through!

I have never insisted on any such thing for LMTP. In fact I have from the start
of this debate back in 2006 pointed out the problems with treating LMTP as as a
case similar to SMTP.

My issue has always been that I'm against making an incompatible change to
_reject_, one that will render existing widely deployed implementations like
ours incompliant. And while we do use LMTP in our product, our Sieve
implementation operates at the SMTP level, not the LMTP level, so for me at
least there is no backwards compatibility issue with LMTP at all.

> >> also, let's change
> >>     using the ereject action, as it is more suitable for such
> >> rejections.
> >> to
> >>     using the ereject action, as reject is unsuitable for such
> >> rejections.
> >
> > The problem with such claims is that the bar they effectively set is so
> > high ereject cannot meet them either. I'm therefore opposed to this as
> > well.

> I don't understand what you're saying here. Can you put it another way?

No, not really.

> >
> >> also, let's change
> >>     support protocol level rejection, e.g. an MUA, and MUST be available
> >> to
> >>     support protocol level rejection, i.e. an MUA, and MUST be available
> >
> > It is entirely possible for there to be critters in the email universe
> > that act
> > at the UA level but which aren't thought of as UAs. So what you are doing
> > actually weakens the requirement by making it sound like it only
> > applies to
> > MUAs specifically.

> Have you thought of an example you can provide?

List processors are the most obvious example of something seen as operating
with MUA authority that people don't think of as an MUA. use of basic Sieve in
conjunction with list processing seems like a pretty reasonasble fit to me.

> >> I still strongly support requiring a change to the default behaviour,
> >> and feel that there is reluctance to change the current behaviour for
> >> what was presented as nothing more than an unwillingness to explain what
> >> we all agreed were net good reasons for the change.
> >
> > I fail to see continuing to impugn the motives for the position I have
> > taken is
> > in any way helpful here. But in the interests of keeping this civil
> > I'm not
> > going to respond further.

> I've said that the justification is poor.  It's not about you; it's not
> ad hominem, so please don't paint it as such.  The point is that the
> evidence/argument provided against chaning the default behaviour is weak.

Hundreds of sites at least. Thousands of machines. Many tens of millions of
users. All operating in full compliance with the original Sieve specification,
not using reject to deal with spam, and AFAIK not a demonstable source of
blowback spam.

Seems like a pretty good justification to me for not wanting to break
backwards compatibility.

Now, if you're after a specific use-case where this really matters, I can
provide that as well. The case we run into all the time is in places like Japan
where limiting rejection text to US-ASCII is widely seen as completely
unacceptable. These folks insist that when rejecting legitimate mail (not spam
blocking) the response go back in proper Japanese. Heck, they get really tense
if just the spacing gets screwed up for some reason.

(On a side note, I'm not even sure that extending SMTP to allow UTF-8 error
responses will be an acceptable alternative to DSNs or MDNs here. I have spent
literally dozens of hours dealing with Japanese format and presentation issues
in nondelivery notifications of various sorts.)

These folks will NOT be happy if all of a sudden the rejects they currently
have in their scripts all of a sudden start returning SMTP level responses
saying "generically offensive system response in i-default has replaced nice
Japanese response that probably managed to bow three times and be extremely 
apologetic and probably made it the recipients fault for not being able to
accept whatever the sender sent". Of course they won't complain - they don't do
that - but they may look elsewhere for their email software. And I happen to
know that there are several implementations out there using Sieve that have no
problem whatsoever ignoring the parts of the standards they find inconvenient.

> >> And I'm not clear why this is needed; I don't think it's the case:
> >> (However, the LMTP client may then have no choice
> >>     but to generate a DSN to report the error, which may result in
> >>     blowback.)
> >> Where it appears to be the case, the LMTP client may just need to be
> >> fixed.
> >
> > Fixed how? Suppose the LMTP client is on an ingress MTA. Messages come
> > in from the Internet using SMTP and are then sent on using LMTP to affect
> > final delivery.

> I suspected you'd be bringing this case up again.
> It needs to be fixed if it accepts the message before it has determined
> whether it should receive it.

But that's operating at the SMTP level, not the LMTP level. And the only
way to enforce that is to not allow LMTP server-side implementation of
ereject.

But if that's the consensus for what we want to do (and while I personally
don't object I've seen no consensus for such a change) then we need to come out
and say that explicitly, not try and eliminate the case by first including LMTP
as a possible place for ereject to be used but then trying to Venn-diagram it
out of existance with a bunch of complex overlapping requirements LMTP cannot
meet.

The approach you're advocating is a sure-fire recipe for confused implementors 
and broken implementations.

> (This discussion has already been hashed out; it's a bit frustrating to
> have to go through it again.)

Well, that discussion apparently did not result in even a mention being added
of the likely consequences of LMTP server-side use of rereject, so apparently
it didn't stick.

> > Suppose the Sieve implementation is operating as part of the LMTP
> > server. (This
> > isn't how I'd ever do it, but it is nevertheless a perfectly legitimate
> > implementation option.) A message comes in via SMTP and is queued for
> > delivery. The LMTP client sends it to the LMTP server, which then runs
> > the Sieve which then does an ereject. This is then translated into a
> > 550 LMTP response.
> >
> > What is the MTA supposed to do now?

> You're asking me what to do once you've painted yourself into a corner.
> My answer is: DON'T paint yourself into a corner.

And the only way to avoid the corner (in the ereject case at least) is not
to operate at the LMTP server level.

More generally, however, there's no way to avoid this case. We go to a lot of
trouble to try and detect things like over quota conditions so we can reject at
the SMTP level. But this depends on back-channel communication to our MTA from
our store. If our MTA is used with someone else's LMTP server - as it sometimes
is - we have no way to perform a useful check at the SMTP level.

> Do I sympathize with you for painting yourself in a corner?  Sure.  But
> if you insist on doing it in perpetuity, I don't.

The only thing I insist on in not to gratuitously make existing implementations
incompliant.

> Do the TCP or Ethernet specs say send data as fast as you please?  No;
> why should we say do what you please here just because there's a market
> for such harmful product?

This is an invidious comparison and shame on you for making it.  It would be
one thing if our implementation had violated the recommendations made by
existing standards and, say, implemented an MDN-generating reject when the
standard said not to and then encouraged its used for dealing with  spam (again
when the standard said such usage was inappropriate). BUt that's not what we
did. What we did was follow the standards quite carefully, including doing
everything we can to prevent our customers from using reject, with its
MDN-generating characteristics, from being used to deal with spam.

 If you've written an ingress MTA to always
> accept mail before determining that the final delivery can be made, then
> you have reasons to paint yourself into a corner: laziness, defense of
> market niche, the system/software you've written works better that
> way...  Good enough reasons?  Not IMO.

And this, Matthew is an ad hominem attack - nothing more and nothing less -
made all the worse because it grossly mischaracterizes what our implementation
does and the reasons why it does it.

And at this point I'm done arguing about this. You, sir, either are an
anti-spam zealot or a very good imitation of one, and I see no point in
continuing to discuss this with you.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IIMFll015466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 11:22:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IIMFwH015463; Wed, 18 Jun 2008 11:22:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IIMDUs015440 for <[e-mail]>; Wed, 18 Jun 2008 11:22:14 -0700 (MST) (envelope-from [e-mail])
Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 96DB6123658; Wed, 18 Jun 2008 14:22:13 -0400 (EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 18 Jun 2008 14:22:13 -0400
X-Sasl-enc: xAX01yqqT+zd5BTnH/4JpqYXQQ7lUg3KFuqqwjWHOMXd 1213813332
Received: from [192.168.18.136] (c-67-169-60-252.hsd1.ca.comcast.net [67.169.60.252]) by mail.messagingengine.com (Postfix) with ESMTPSA id 9E44715E0C; Wed, 18 Jun 2008 14:22:12 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 18 Jun 2008 11:22:11 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 3.0a1 (Macintosh/2008050714)
MIME-Version: 1.0
To: [e-mail]
CC: Ned Freed <[e-mail]>
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 5/29/08 9:22 AM, Ned Freed wrote:
> <Ned quote me but didn't include a quotation line; please do so in 
> future, Ned.>:
>
>
>> I disagree.  There is a loophole for an implementer to decide that 
>> what he or
>> she feels is preferred is to not bother fulfilling this requirement. 
>> It needs
>> to be closed.
>
> Then you really need to provide better evidence that such a loophole 
> exists -
> because I'm not seeing it.
That's funny.  You do see it.  You just don't realize it.  You drove the 
LMTP truck through the loophole!! (see LMTP discussion below)  My latest 
draft doesn't have the loophole that you've insisted LMTP 
implementations should be able to drive through!
>> I also support the addition of the text Ned proposed:
>
>> "the risk that these actions will generate blowback spam are
>> minimized but cannot be eliminated completely even in the case of 
>> ereject, so
>> caution is advised when using these actions to deal with messages 
>> determined to
>> be spam."
>
>> It can go at the end of 2.1.2.
>
> 2.1.2 discusses sending DSNs and is therefore entirely the wrong place 
> for
> this. It belongs at the end of 2.1.1, the section talking about 
> SMTP/LMTP level
> rejects.
Agreed.
>
>
>> and I don't see why
>>     Script generators SHOULD ensure that a rejection action being
>> shouldn't be
>>     Script generators MUST ensure that a rejection action being
>
> This cannot be a MUST, if for no other reason that such generators could
> easily be operating in an MUA content where ereject is not available.
Agreed.
>
>> also, let's change
>>     using the ereject action, as it is more suitable for such 
>> rejections.
>> to
>>     using the ereject action, as reject is unsuitable for such 
>> rejections.
>
> The problem with such claims is that the bar they effectively set is so
> high ereject cannot meet them either. I'm therefore opposed to this as 
> well.
I don't understand what you're saying here. Can you put it another way?
>
>> also, let's change
>>     support protocol level rejection, e.g. an MUA, and MUST be available
>> to
>>     support protocol level rejection, i.e. an MUA, and MUST be available
>
> It is entirely possible for there to be critters in the email universe 
> that act
> at the UA level but which aren't thought of as UAs. So what you are doing
> actually weakens the requirement by making it sound like it only 
> applies to
> MUAs specifically.
Have you thought of an example you can provide?

>> I still strongly support requiring a change to the default behaviour,
>> and feel that there is reluctance to change the current behaviour for
>> what was presented as nothing more than an unwillingness to explain what
>> we all agreed were net good reasons for the change.
>
> I fail to see continuing to impugn the motives for the position I have 
> taken is
> in any way helpful here. But in the interests of keeping this civil 
> I'm not
> going to respond further. 
I've said that the justification is poor.  It's not about you; it's not 
ad hominem, so please don't paint it as such.  The point is that the 
evidence/argument provided against chaning the default behaviour is weak.
>
>> And I'm not clear why this is needed; I don't think it's the case:
>> (However, the LMTP client may then have no choice
>>     but to generate a DSN to report the error, which may result in
>>     blowback.)
>> Where it appears to be the case, the LMTP client may just need to be
>> fixed.
>
> Fixed how? Suppose the LMTP client is on an ingress MTA. Messages come
> in from the Internet using SMTP and are then sent on using LMTP to affect
> final delivery.
I suspected you'd be bringing this case up again.
It needs to be fixed if it accepts the message before it has determined 
whether it should receive it.
(This discussion has already been hashed out; it's a bit frustrating to 
have to go through it again.)

>
> Suppose the Sieve implementation is operating as part of the LMTP 
> server. (This
> isn't how I'd ever do it, but it is nevertheless a perfectly legitimate
> implementation option.) A message comes in via SMTP and is queued for
> delivery. The LMTP client sends it to the LMTP server, which then runs
> the Sieve which then does an ereject. This is then translated into a
> 550 LMTP response.
>
> What is the MTA supposed to do now? 
You're asking me what to do once you've painted yourself into a corner.  
My answer is: DON'T paint yourself into a corner.

Do I sympathize with you for painting yourself in a corner?  Sure.  But 
if you insist on doing it in perpetuity, I don't.

Do the TCP or Ethernet specs say send data as fast as you please?  No; 
why should we say do what you please here just because there's a market 
for such harmful product? If you've written an ingress MTA to always 
accept mail before determining that the final delivery can be made, then 
you have reasons to paint yourself into a corner: laziness, defense of 
market niche, the system/software you've written works better that 
way...  Good enough reasons?  Not IMO.

> It has exactly two options available:
>
> (1) Silently discard the message.
> (2) Generate a DSN and send it to the MAIL FROM address.
>
> (1) is only appropriate if the MAIL FROM is emoty, NOTIFY=NEVER is in 
> effect,
> the MAIL FROM Is somehow known to be forged. That leaves generating a 
> DSN as the only viable alternative in most cases.
>
> Returning a 550 SMTP response is not possible for the simple reason 
> that the
> SMTP connection is long gone - in fact it could have taken place hours 
> or even
> days earlier.
> I will also note that the behavior of such an MTA, which not only 
> isn't the
> agent with the Sieve implementation, it likely will not even be aware 
> that
> Sieve is involved, is entirely out of scope for this working group. We 
> cannot
> impose requirements here even if we wanted to.
>
>> If there is indeed such a case, it needs to be specified.
>
> Specify what? 
Do what you did.
> The unfortunate reality is that once a message has been accepted
> by an ingress MTA the options for getting rid of it narrow down to 
> discarding it, with or without sending a notification.
> Now, I have long been a proponent of turning away as many messages as 
> possible
> while the connection is still there for reporting errors. But neither 
> this
> document nor this workging group are the places to make the case for 
> doing
> things this way.
>
>> Oh, and the acronyms MDA,  MTA and MUA are now used but not defined (as
>> Mail Delivery, Transfer and User Agents, respectively)
>> draft-crocker-email-arch-10.txt defines 'em, but it's been an I-D for as
>> long as this I-D, so I suggest we just spell 'em out on initial use.
>
> I agree the terms need to be defined but the right way to do is is by
> referencing the architecture document. The Sieve environment draft did 
> so and
> this has not proved to be a barrier to publication.
Ok.  Defined or just spelled out; either is fine with me.
>
>                 Ned



-Matthew