headers
Matthew Elvey | 18 Jun 2008 20:22
Picon

Re: draft-ietf-sieve-refuse-reject-07.txt


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.
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ned Freed | 19 Jun 2008 02:21

Re: draft-ietf-sieve-refuse-reject-07.txt


> 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.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Matthew Elvey | 19 Jun 2008 21:43
Picon

Re: draft-ietf-sieve-refuse-reject-07.txt


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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kjetil Torgrim Homme | 20 Jun 2008 10:46
Picon
Picon

Re: draft-ietf-sieve-refuse-reject-07.txt


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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arnt Gulbrandsen | 20 Jun 2008 12:15
Picon
Favicon
Gravatar

Re: draft-ietf-sieve-refuse-reject-07.txt


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
Permalink | Reply | 1 comment |
headers
Cyrus Daboo | 20 Jun 2008 16:13
Favicon

Re: draft-ietf-sieve-refuse-reject-07.txt


Hi folks,

--On June 20, 2008 12:15:35 PM +0200 Arnt Gulbrandsen 
<arnt <at> gulbrandsen.priv.no> 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
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 22 Jun 2008 16:27
Favicon

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


Internet-Drafts <at> ietf.org 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.
(Continue reading)

Permalink | Reply | 25 comments |
headers
Alexey Melnikov | 25 Jun 2008 17:18
Favicon

Status of the Sieve WG drafts


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>
Permalink | Reply | 0 comments |
headers
Stephan Bosch | 28 Jun 2008 22:24
Picon

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


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.
(Continue reading)

Permalink | Reply | 22 comments |
headers
Alexey Melnikov | 29 Jun 2008 20:00
Favicon

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


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.
(Continue reading)

Permalink | Reply | 21 comments |

Gmane