SIEVE Statistics

["Madan Ganesh Velayudham" <[e-mail]>]

Hi,

I've sent out a draft for collecting SIEVE statistics.

Abstract

    This draft describes a mechanism of collecting the statistical
    information about sieve action on the received mail. It 
    introduces GETSTAT and RESETSTAT commands to [MSIEVE] to get and 
    reset the statistic information about the sieve actions.

Waiting for the I-D.

Cheers,
MG



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAM1xUkT096146 for <[e-mail]>; Fri, 21 Nov 2003 17:59:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAM1xUFn096145 for ietf-mta-filters-bks; Fri, 21 Nov 2003 17:59:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAM1xSkT096137 for <[e-mail]>; Fri, 21 Nov 2003 17:59:29 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel9.hp.com (Postfix) with ESMTP id 626BC1C00A45 for <[e-mail]>; Fri, 21 Nov 2003 20:59:26 -0500 (EST)
Received: from lappool (js741821.cup.hp.com [15.13.130.160]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id HAA24168 for <[e-mail]>; Sat, 22 Nov 2003 07:28:08 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Subject: SIEVE Statistics
Date: Sat, 22 Nov 2003 07:29:22 +0530
Message-ID: <000101c3b09c$40bc87f0$a0820d0f@lappool>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[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>

Hi,

I've sent out a draft for collecting SIEVE statistics.

Abstract

    This draft describes a mechanism of collecting the statistical
    information about sieve action on the received mail. It 
    introduces GETSTAT and RESETSTAT commands to [MSIEVE] to get and 
    reset the statistic information about the sieve actions.

Waiting for the I-D.

Cheers,
MG



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIGqokT073284 for <[e-mail]>; Tue, 18 Nov 2003 08:52:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIGqoTM073283 for ietf-mta-filters-bks; Tue, 18 Nov 2003 08:52:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIGqlkT073276 for <[e-mail]>; Tue, 18 Nov 2003 08:52:49 -0800 (PST) (envelope-from [e-mail])
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id hAIGqg3w007714 for <[e-mail]>; Tue, 18 Nov 2003 11:52:42 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2003 11:53:00 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IETF MTA Filters List <[e-mail]>
Subject: draft-murchison-sieve-regex-07.txt
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>

As per the latest Sieve BOF, I have just sent in an update to the regex 
extension:

http://www.oceana.com/ftp/drafts/draft-murchison-sieve-regex-07.txt
ftp://ftp.oceana.com/pub/drafts/draft-murchison-sieve-regex-07.txt

The major outstanding issues are what to do (if anything) about il8n, 
and should we allow the use of additional regex expressions, such as 
backreferences and/or variables.

Both of the last two items work with grouped parts of the regex but have 
a very subtle difference; the former is used within the regex and the 
latter is used outside of the regex.  Backreferences would probably be 
more useful with a body test (e.g. for matching HTML tags, etc) than 
with header or address/envelope test.  Here are examples (quite possibly 
cooked) of both:


# Backreferences example - Discard any subjects with double words
if header :regex "subject" "([A-Za-z]+) +\\1" {
   discard;
}

# Variables example - File IETF WG mail
if envelope :regex "from" "ietf-(.+)@imc.org" {
   fileinto "INBOX.ietf.$1;
}

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADFk3kT063370 for <[e-mail]>; Thu, 13 Nov 2003 07:46:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADFk3Ka063369 for ietf-mta-filters-bks; Thu, 13 Nov 2003 07:46:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADFk1kT063354 for <[e-mail]>; Thu, 13 Nov 2003 07:46:02 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AKJfS-0005Lh-B2; Thu, 13 Nov 2003 16:45:58 +0100
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AKJfO-0005Ti-Eu; Thu, 13 Nov 2003 16:45:54 +0100
Subject: Re: SIEVE lunch summary
From: Kjetil Torgrim Homme <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Thu, 13 Nov 2003 16:45:50 +0100
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning.
X-UiO-MailScanner: No virus found
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, 2003-11-13 at 04:11, Cyrus Daboo wrote:
> variables: consensus that it is important to complete this asap. Cyrus has 
> a new date draft (out soon - see below) that may overlap with date 
> variables. Should date items be removed from variables: yes - lets pare 
> variables down to the essentials. Date stuff can go in Cyrus' draft if it 
> makes sense. Ned has partial draft on date tests - will send to Cyrus. Wait 
> to see date draft before deciding exactly what to do.

ACK.  will have time to do a new version of draft next week.

-- 
Kjetil T.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAD3BAkT059488 for <[e-mail]>; Wed, 12 Nov 2003 19:11:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAD3BATk059486 for ietf-mta-filters-bks; Wed, 12 Nov 2003 19:11:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAD3B8kT059481 for <[e-mail]>; Wed, 12 Nov 2003 19:11:09 -0800 (PST) (envelope-from [e-mail])
Received: from dyn135-151.ietf58.ietf.org (dyn135-151.ietf58.ietf.org [130.129.135.151]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hAD31EEG030008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 12 Nov 2003 22:01:20 -0500
Date: Wed, 12 Nov 2003 21:11:02 -0600
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: SIEVE lunch summary
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.0 (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>

Summary of SIEVE Lunch, IETF 58, Minneapolis 17-Nov-2003

Present in person: Cyrus, Rob, Chris, Phillip, Madan, Randy
Present on Jabber: Ned, Alexey, Ken, Arnt

current docs: <http://www.cyrusoft.com/sieve/documents.html>
jabber log: 
<http://www.xmpp.org/ietf-logs/[e-mail]/2003-11-12.txt>

I have summarised comments for each draft in their own section, even though 
the discussion of some of them was interleaved due to jabber lag and some 
of us taking a break to eat.

Discussion on existing drafts:

imapflags: some implementations exist. Should we last call? Not yet, its 
tied to variables very tightly and thus cannot proceed until variables is 
nailed down. Should name be changed because of recent incompatible changes? 
Final suggestion for new name: imap4flags.

vacation: new from address option proposed. Question is how to deal with 
MIME encoding. Suggestion: server MUST support utf-8 encoding of non-ascii 
from parameter, and MAY support encoding in some other appropriate 
character set. Client MAY do MIME encoding itself. Ned wanted alignment 
with Keith Moore's auto-responder draft: resent headers must be tested as 
well as regular to/cc/bcc.

variables: consensus that it is important to complete this asap. Cyrus has 
a new date draft (out soon - see below) that may overlap with date 
variables. Should date items be removed from variables: yes - lets pare 
variables down to the essentials. Date stuff can go in Cyrus' draft if it 
makes sense. Ned has partial draft on date tests - will send to Cyrus. Wait 
to see date draft before deciding exactly what to do.

regex: i18n problems - two solutions (1) ignore for now using 
case-insensitive ascii and octet-stream comparators, (2) wait for Chris 
Newman's comparator draft. Discussion on evil regex tests & utf-8 took 
place. Should we opt to publish as experimental and gloss over i18n issues? 
Rough consensus. Use reference to unicode technical spec in the draft. OK - 
lets rev the current draft and punt the i18n issue to the list.

managesieve: need to clean up - refs to latest sasl work, id nits, 
references etc. URL scheme and sasl profile name need to be changed to 
managesieve. STARTTLS issue with virtual hosts: can be done as extension. 
Ned will re-post his issues to the list. Rob will endeavour to get Tim to 
do a new draft asap, or will take over the job himself.

notify: draft is currently expired. Need to get it updated. Some 
implementations, e.g. sms messages. Rob will again prompt Tim for an update 
or take over himself.

body: Jutta will have an update out shortly. Will do list last call on that.

spamtest: in IESG last call right now.

include: how to deal with missing scripts? Error at runtime seems to be 
consensus. Need way to list global scripts in managesieve - Chris: allowing 
users to see the contents of global scripts is bad - could cause legal 
problems. Include will define managesieve extension for listing available 
global scripts only. It would be useful to have a managesieve extension to 
check a script against a supplied message to see errors or results - Randy 
volunteered to work on a draft.

multiscript: need more review of this document. Punt to list.

editheader: one 'hacked' implementation. Punt to list for further review.

copy: Consensus was to list last call it.

Discussion on new drafts:

Cyrus will submit mime header test draft in the next few days.

Cyrus will submit date test draft in the next few days.

Cyrus has report/trace draft in the works. Proposal: to allow users to turn 
on logging/tracing of actions on filtered messages. Two possible outcomes 
(1) addition of headers with trace info, (2) dsn with trace info sent to 
email address or fileinto'd a specific mailbox. Chris suggested just use 
(2). Hidden headers are bad. Ned has a similar capture extension - actually 
not the same. Any interest in also writing up capture - general 
indifference on that point.

Other issues:

fileinto + auto-create mailbox behaviour: consensus that the default 
behaviour is up to the implementation, but we need specific options to 
explicitly turn on or off auto-create as required by client. Not sure 
whether this was proposed in a draft before - possibly not. Phil will bring 
this to Jutta's attention.



-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACIi9kT038068 for <[e-mail]>; Wed, 12 Nov 2003 10:44:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACIi9K4038065 for ietf-mta-filters-bks; Wed, 12 Nov 2003 10:44:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACIi8kT038060 for <[e-mail]>; Wed, 12 Nov 2003 10:44:08 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 12 Nov 2003 10:44:06 -0800 (PST)
Date: Wed, 12 Nov 2003 10:44:06 -0800 (PST)
From: [e-mail]
Subject: Repost of earlier review comments on managesieve
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: message/rfc822
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>

Return-path: <[e-mail]>
Received: from gate.innosoft.com ([192.160.253.77])
 by mauve.mrochek.com (PMDF V6.1-1 #35243)
 with ESMTP id <[e-mail]> for
 [e-mail]; Fri, 17 Oct 2003 10:53:20 -0700 (PDT)
Received: from psmtp.com ([12.158.34.141])
 by GATE.INNOSOFT.COM (PMDF V6.0-24 #10099)
 with SMTP id <[e-mail]> for
 [e-mail] (ORCPT [e-mail]); Fri,
 17 Oct 2003 10:51:50 -0700 (PDT)
Received: from source ([208.184.76.39]) by exprod5mx1.postini.com
 ([12.158.34.245]) with SMTP; Fri, 17 Oct 2003 10:51:48 -0700 (PDT)
Received: from above.proper.com (localhost [127.0.0.1])
 by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HHRNI7018663 for
 <[e-mail]>; Fri, 17 Oct 2003 10:27:23 -0700
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit)
 id h9HHRNNH018662 for ietf-mta-filters-bks; Fri,
 17 Oct 2003 10:27:23 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55])
 by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HHRLI7018657 for
 <[e-mail]>; Fri,
 17 Oct 2003 10:27:21 -0700 (PDT envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <[e-mail]> for [e-mail]; Fri,
 17 Oct 2003 10:27:05 -0700 (PDT)
Date: Fri, 17 Oct 2003 09:08:41 -0700 (PDT)
From: [e-mail]
Subject: Review comments on draft-martin-managesieve-04.txt
In-reply-to: "Your message dated Sat, 09 Aug 2003 10:09:44 +0100"
 <0ade01c35e55$f9904a80$6501a8c0@nigelhome>
Sender: [e-mail]
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Precedence: bulk
X-pstn-levels: (S:56.8076 R:95.9108 P:95.9108 M:99.2559 C:86.9899 )
X-Authentication-warning: above.proper.com: majordom set sender to
 [e-mail] using -f
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Id: <ietf-mta-filters.imc.org>
Original-recipient: rfc822;[e-mail]
Spam-test: False ; -0.1 / 4.5 ; IN_REP_TO,NO_REAL_NAME,X_AUTH_WARNING


It was recently mentioned on the imapext list that it is time to get
the managesieve protocol spec moving forward. So I decided to take a look
at the specification as it stands. My comments are as follows:

(0) In keeping with IESG feedback on the sieve subaddress specification, I
    think the title needs to be changed to "A Protocol for Remotely Managing
    Sieve Email Filtering Scripts".

(1) The second paragraph of the introduction regarding ACAP should only
    appear in the introduction (see next point), not in the abstract.

(2) This specification really needs an introduction. Currently the
    introduction section is blank. I suggest an extended version of the
    abstract, something along the lines of:

  Scripts written in the sieve [SIEVE] language allow users to specify
  filters for the email they receive. Typically each user of a message
  store can have his or her own private sieve script or scripts.
  However, 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 "sieve" 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.

  This an interim measure as it is hoped that eventually Sieve scripts
  will be stored on ACAP. This document is intended to proceed on the
  experimental track.

(3) Section 1.1 needs to be marked as needing to be removed prior to
    publication.

(4) Sections 1.3 and later really don't belong as subsections of the
    introduction. I suggest moving all of these up a level.

(5) Section 1.3, first paragraph, second sentence. Three types of what?
    Tokens? And why is ATOMS capitalized?

(6) It seems to me section 1.3, Syntax, should provide a prose description
    of the syntax of responses as well as that for commands.

(7) The bit about the port number in section 1.3 really needs to be in a
    section other than one on syntax. Perhaps a section of its own is
    appropriate? It could contain the usual prose about how managesieve
    servers listen for connections on TCP port <tbd>. It also should be
    make it clear that the prose about port 2000 needs to be removed prior
    to publication.
   
(8) Section 1.7 and probably elsewhere. "UTF8" -> "UTF-8".

(9) Sieve script names are UTF-8 identifiers, and as such would seem to me
    to be subject to UTF-8 normalization concerns. The usual way this is
    dealt with is to specify an appropriate stringprep scheme to use. (Indeed,
    the specification appears to be silent on whether or not even ASCII
    script names are case sensitive.) I'm tempted to say that the right
    course of action is to simply reuse the nameprep stringprep profile
    defined in RFC 3491, but this assumes case-insensitivity is what you want.

(10) Section 1.8, paragraph prior to example. "any other capabilities given" ->
     "any capabilities given".

(11) Section 2.1, second example. There probably should be an ellipsis or
    something similar at the begining to indicate these aren't the first
    commands in a session.

(12) Section 2.8. Should make it clear any previously active script is
     deactivated. There's also the question of what happens to the currently
     active script when SETACTIVE is specified with a bogus script name.
     Does the currently active script remain active or is no script active
     after this is done? Need to be specific either way.

(13) Section 3, Sieve URL scheme. A couple of problems here. First, the
     function of this URL scheme needs to be stated in prose prior to the
     registration template. Second, given that the URL can either be
     used to identify either a managesieve server or a script on that
     server, doesn't the scriptname have to be an optional part of the
     URL? Third, I think the name "sieve" is too general for any URL
     scheme in this document -- it is entirely possible there will be other
     URLs that deal with sieve in some way. I suggest "managesieve" instead. 
     And finally, the usage section talks about a "sieve server". Isn't
     this a "managesieve" server?

(14) Section 4, ABNF. The rules iana-token and extension-data
     aren't defined in this specification and the only external rules that
     are inherited are the ones from the base ABNF specification. It looks
     to me like the reference for these rules that needs to be added is
     ACAP (RFC 2244). And there's also the issue of references to the
     sieveurl ABNF given in section 3. The simplest way to deal with this
     would be one more sentence saying it also refers to the sieveurl
     production defined in section 3.

(15) Section 5, second paragraph. Doesn't TLS, properly implemented, also
     provide protection against passive observation and MITM attacks?
     A pointer to the security considerations for sieve itself in RFC 3028
     would probably be a good thing to add as well.

(16) This document needs an IANA considerations section that tells IANA
     to register the URL scheme defined in section 3 and to assign a port
     for the managesieve protocol to use.

(17) Reference to [imap4rev1] needs to be updated from RFC 2060 to RFC 3501.

(18) References need to be split into normative and informative groups.

(19) Indentation of first reference doesn't match the rest.

(20) The required IPR boilerplate section is missing from this document.
     See, say, RFC 3598 section 8 for what this needs to contain.

That's it!

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACIF0kT036648 for <[e-mail]>; Wed, 12 Nov 2003 10:15:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACIF0xP036647 for ietf-mta-filters-bks; Wed, 12 Nov 2003 10:15:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACIEwkT036642 for <[e-mail]>; Wed, 12 Nov 2003 10:14:59 -0800 (PST) (envelope-from [e-mail])
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id hACIEs3w002402; Wed, 12 Nov 2003 13:14:54 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 12 Nov 2003 13:15:04 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: SIEVE Lunch Agenda Suggestions
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Cyrus Daboo wrote:

> 
> We still plan on holding a SIEVE lunch at the IETF meeting tomorrow 
> (Wednesday). Those attending should meet at the back of the Rochester 
> room at the end of the IMAPext meeting. We will try and use the cafe in 
> the hotel lobby so we can have people attend via Jabber.
> 
> Here is a suggestion for an agenda:
> 
> - Discussion of current drafts:
> 
> regex

Since you guys are having trouble with jabber, here are some outstanding 
issues with regex:

- il8n?

- do we allow backreferences? e.g.  '(.*)\1'

- do we allow the use of variables?  e.g. for the regex '(.*)xxx(.*)', 
$1 would contain the contents of the first () and $2 would contain the 
contents of the second ()

- do we allow use of macros such as \w (word match)?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACI9hkT036432 for <[e-mail]>; Wed, 12 Nov 2003 10:09:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACI9hje036431 for ietf-mta-filters-bks; Wed, 12 Nov 2003 10:09:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACI9gkT036416 for <[e-mail]>; Wed, 12 Nov 2003 10:09:42 -0800 (PST) (envelope-from [e-mail])
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id hACI9b3w002324; Wed, 12 Nov 2003 13:09:37 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 12 Nov 2003 13:09:48 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Rob Siemborski <[e-mail]>
CC: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SIEVE lunch at IETF?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Rob Siemborski wrote:

> On Thu, 6 Nov 2003, Alexey Melnikov wrote:
> 
> 
>>Information about jabber:
>>http://www.xmpp.org/ietf-chat.html
>>
>>Jabber conference room for Sieve should be "sieve".
> 
> 
> We're currently working on connecting to jabber, but it appears that the
> jabber.org server is not responding, atleast not for us ;)

I saw you come online at [e-mail].  Which server are you using 
for the sieve group?  I assumed that it would be ietf.xmpp.org

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACHgZkT035667 for <[e-mail]>; Wed, 12 Nov 2003 09:42:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACHgZZR035666 for ietf-mta-filters-bks; Wed, 12 Nov 2003 09:42:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACHgTkT035658 for <[e-mail]>; Wed, 12 Nov 2003 09:42:29 -0800 (PST) (envelope-from [e-mail])
Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hACHgTWj006270; Wed, 12 Nov 2003 12:42:29 -0500
Date: Wed, 12 Nov 2003 12:42:30 -0500 (EST)
From: Rob Siemborski <[e-mail]>
To: Alexey Melnikov <[e-mail]>
cc: [e-mail]
Subject: Re: SIEVE lunch at IETF?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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, 6 Nov 2003, Alexey Melnikov wrote:

> Information about jabber:
> http://www.xmpp.org/ietf-chat.html
>
> Jabber conference room for Sieve should be "sieve".

We're currently working on connecting to jabber, but it appears that the
jabber.org server is not responding, atleast not for us ;)

we'll try to take notes, and if it starts working miraculously we'll sign
in.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [e-mail] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABL2lkT021222 for <[e-mail]>; Tue, 11 Nov 2003 13:02:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABL2l6g021221 for ietf-mta-filters-bks; Tue, 11 Nov 2003 13:02:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABL2jkT021215 for <[e-mail]>; Tue, 11 Nov 2003 13:02:46 -0800 (PST) (envelope-from [e-mail])
Received: from dyn130-12.ietf58.ietf.org (dyn130-12.ietf58.ietf.org [130.129.130.12]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hABKqcEG002700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Nov 2003 15:53:08 -0500
Date: Tue, 11 Nov 2003 15:02:16 -0600
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: SIEVE Lunch Agenda Suggestions
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.0 (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>

We still plan on holding a SIEVE lunch at the IETF meeting tomorrow 
(Wednesday). Those attending should meet at the back of the Rochester room 
at the end of the IMAPext meeting. We will try and use the cafe in the 
hotel lobby so we can have people attend via Jabber.

Here is a suggestion for an agenda:

- Discussion of current drafts:

imapflags
vacation
regex
managesieve
notify
body
spamtest
include
variables
multiscript
editheader
copy

- Discussion of new drafts:

mime (mime headers tests)
date (tests against dates)
report (allowing logging of sieve actions for end-users)


If you have any additional items for the list above please let me know. 
Also, if you  are an author of any of the above and won't be able to 
participate in the meeting and want to provide an update on your document, 
please send something to me and I will make sure it gets mentioned at the 
meeting.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LNVkT030998 for <[e-mail]>; Thu, 6 Nov 2003 13:23:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6LNVqG030997 for ietf-mta-filters-bks; Thu, 6 Nov 2003 13:23:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6LNTkT030992 for <[e-mail]>; Thu, 6 Nov 2003 13:23:30 -0800 (PST) (envelope-from [e-mail])
Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 6 Nov 2003 21:24:41 +0000
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2003 21:23:29 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: SIEVE lunch at IETF?
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Information about jabber:
http://www.xmpp.org/ietf-chat.html

Jabber conference room for Sieve should be "sieve".

Alexey




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FjQkT085415 for <[e-mail]>; Wed, 5 Nov 2003 07:45:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FjQv8085414 for ietf-mta-filters-bks; Wed, 5 Nov 2003 07:45:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FjPkT085409 for <[e-mail]>; Wed, 5 Nov 2003 07:45:25 -0800 (PST) (envelope-from [e-mail])
Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 Nov 2003 15:46:28 +0000
Message-ID: <[e-mail]>
Date: Wed, 05 Nov 2003 15:45:22 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thoralf Will <[e-mail]>
CC: [e-mail]
Subject: Re: running a script after a certain delay
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Thoralf Will wrote:

>Hi all,
>
>is there any implementation/idea/suggestion available already to run a
>script after a certain time has passed?
>
>Example:
>Mail from [e-mail] arrives and gets delivered, the usual scripts are
>running and put it into a special folder.
>A 2nd script starts 1h later, looks for a mail in this special folder
>and does something (redirect again, autoreply ...) if there is still a
>mail.
>
>Is this possible
>
The way you describe it, the 2nd script is just being executed by a 
special type Mail User Agent.

>and when how or are there any intentions to implement
>something like this?
>  
>
Can you be more specific. For the task you describe, I don't see any 
need to modify/extend Sieve.

If you are looking for a product that can do that, you should at least 
tell us what is your OS requirement.

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FYTkT084991 for <[e-mail]>; Wed, 5 Nov 2003 07:34:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FYSRG084990 for ietf-mta-filters-bks; Wed, 5 Nov 2003 07:34:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FYRkT084974 for <[e-mail]>; Wed, 5 Nov 2003 07:34:27 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id 8E5A51C02215; Wed,  5 Nov 2003 07:34:26 -0800 (PST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id VAA22128; Wed, 5 Nov 2003 21:03:12 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: "'Rob Siemborski'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Fileinto-except
Date: Wed, 5 Nov 2003 21:04:26 +0530
Organization: Hewlett-Packard STSD
Message-ID: <00a301c3a3b2$4b8db470$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[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>

Hi Rob,

	Sorry for not describing the scope of this draft.

	Initially I would like to get comments like whether such an
	feature is already available; Basically whether it replicates
	the concept that is already done.

	I shall come up with the proper draft and send it for
discussion.

	Thanks for your understanding,
	MG

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Rob 
> Siemborski
> Sent: Wednesday, November 05, 2003 7:57 PM
> To: Madan Ganesh Velayudham
> Cc: [e-mail]
> Subject: Re: Fileinto-except
> 
> 
> 
> On Wed, 5 Nov 2003, Madan Ganesh Velayudham wrote:
> 
> > 	Please share your views on the attached document.
> >
> > 	I will submit a draft version after the queue is open.
> 
> I'm not really sure there's enough detail in the attached 
> document to go on.  Excluding the lack of normal ID 
> boilerplate and the spelling/grammar problems, there is no 
> syntax for the extension specified, nor are any examples given.
> 
> It is also unclear how the mime part that is being excluded 
> is being specified, or how to exclude more than one mime 
> part.  Without variables (and better body tests), it is 
> unclear to me that you can reliably target a specific mime 
> part in sieve.  (Or do you always just want to get rid of 
> part 2.1 of a message?)
> 
> -Rob
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski | Andrew Systems Group * Research Systems 
> Programmer PGP:0x5CE32FCC | Cyert Hall 207 * 
> [e-mail] * 412.268.7456 -----BEGIN GEEK CODE BLOCK----
> Version: 3.12
> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ 
> N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ 
> DI+++ G e++ h r- y? ------END GEEK CODE BLOCK-----
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FRokT084618 for <[e-mail]>; Wed, 5 Nov 2003 07:27:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FRooM084617 for ietf-mta-filters-bks; Wed, 5 Nov 2003 07:27:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA5FRmkT084611 for <[e-mail]>; Wed, 5 Nov 2003 07:27:48 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 11226 invoked from network); 5 Nov 2003 10:27:49 -0500
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 5 Nov 2003 10:27:49 -0500
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 1670 invoked by uid 101); 5 Nov 2003 10:27:48 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 5 Nov 2003 10:27:48 -0500
To: Thoralf Will <[e-mail]>
Cc: [e-mail]
Subject: Re: running a script after a certain delay
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
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 Wed, Nov 05, 2003 at 01:52:04PM +0100, Thoralf Will wrote:
> 
> Hi all,
> 
> is there any implementation/idea/suggestion available already to run a
> script after a certain time has passed?
> 
> Example:
> Mail from [e-mail] arrives and gets delivered, the usual scripts are
> running and put it into a special folder.
> A 2nd script starts 1h later, looks for a mail in this special folder
> and does something (redirect again, autoreply ...) if there is still a
> mail.
> 
> Is this possible and when how or are there any intentions to implement
> something like this?

That's actually an interesting notion: I assume the point is to give
an autoreply if a human hasn't dealt with an issue soon.  But it sounds
more appropriate for a ticketing system than a final delivery filter.

mm


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5EQckT082062 for <[e-mail]>; Wed, 5 Nov 2003 06:26:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5EQcWp082061 for ietf-mta-filters-bks; Wed, 5 Nov 2003 06:26:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5EQakT082055 for <[e-mail]>; Wed, 5 Nov 2003 06:26:37 -0800 (PST) (envelope-from [e-mail])
Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA5EQaWj027449; Wed, 5 Nov 2003 09:26:36 -0500
Date: Wed, 5 Nov 2003 09:26:36 -0500 (EST)
From: Rob Siemborski <[e-mail]>
To: Madan Ganesh Velayudham <[e-mail]>
cc: [e-mail]
Subject: Re: Fileinto-except
In-Reply-To: <001c01c3a30c$952634f0$3ce62a0f@nt23060>
Message-ID: <[e-mail]>
References: <001c01c3a30c$952634f0$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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 Wed, 5 Nov 2003, Madan Ganesh Velayudham wrote:

> 	Please share your views on the attached document.
>
> 	I will submit a draft version after the queue is open.

I'm not really sure there's enough detail in the attached document to go
on.  Excluding the lack of normal ID boilerplate and the spelling/grammar
problems, there is no syntax for the extension specified, nor are any
examples given.

It is also unclear how the mime part that is being excluded is being
specified, or how to exclude more than one mime part.  Without variables
(and better body tests), it is unclear to me that you can reliably target
a specific mime part in sieve.  (Or do you always just want to get rid of
part 2.1 of a message?)

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [e-mail] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5E0nkT080650 for <[e-mail]>; Wed, 5 Nov 2003 06:00:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5E0nFq080649 for ietf-mta-filters-bks; Wed, 5 Nov 2003 06:00:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5E0mkT080644 for <[e-mail]>; Wed, 5 Nov 2003 06:00:48 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel8.hp.com (Postfix) with ESMTP id 5355E1C00D2A; Wed,  5 Nov 2003 09:00:46 -0500 (EST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id TAA15958; Wed, 5 Nov 2003 19:29:21 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: "'Cyrus Daboo'" <[e-mail]>, <[e-mail]>
Subject: RE: Fileinto-except
Date: Wed, 5 Nov 2003 19:30:35 +0530
Organization: Hewlett-Packard STSD
Message-ID: <009e01c3a3a5$353dcdc0$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[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>

Hi Cyrus,

	Thanks for your comments.


> | 	Please share your views on the attached document.
> |
> | 	I will submit a draft version after the queue is open.
> 
> Is the use of this meant to be to implement some sort of spam/virus 
> checking? If so, then I think this is overloading sieve too 
> far - sieve is 
> not meant to be an anti-spam/anti-virus tool. Instead you 
> should consider 
> using proper tools for that, and hook in the 
> spamtest/virustest extension 
> into sieve.

	I do not want to limit this to spam or virus checking. One of
the requirement
	for this is that I receive mails from certain individuals with
same attachment
	always, which I don't want to have in the mailbox and occupy
space.

	Instead I just be interested in the Main content of the message.

	The received message could indicate "a narration" that the
attachment has been 
	removed for the user.

	I'm planning to leverage imap-remove extension which I've
proposed recently.

	+MG



> 
> -- 
> Cyrus Daboo
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5CqBkT077771 for <[e-mail]>; Wed, 5 Nov 2003 04:52:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5CqBkT077770 for ietf-mta-filters-bks; Wed, 5 Nov 2003 04:52:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5Cq9kT077765 for <[e-mail]>; Wed, 5 Nov 2003 04:52:09 -0800 (PST) (envelope-from [e-mail])
Received: from fwd00.aul.t-online.de  by mailout07.sul.t-online.com with smtp  id 1AHN8r-0003lE-02; Wed, 05 Nov 2003 13:52:09 +0100
Received: from gandalf.cip.de (XdkXIUZr8eyUhlEed12c23-ix+AKM0vo69bQatQCZbeCGKVNJDw9c9@[80.145.241.37]) by fmrl00.sul.t-online.com with esmtp id 1AHN8n-0U46Xg0; Wed, 5 Nov 2003 13:52:05 +0100
Subject: running a script after a certain delay
From: Thoralf Will <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Organization: CipSoft GmbH
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-2) 
Date: Wed, 05 Nov 2003 13:52:04 +0100
Content-Transfer-Encoding: 7bit
X-Seen: false
X-ID: [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>

Hi all,

is there any implementation/idea/suggestion available already to run a
script after a certain time has passed?

Example:
Mail from [e-mail] arrives and gets delivered, the usual scripts are
running and put it into a special folder.
A 2nd script starts 1h later, looks for a mail in this special folder
and does something (redirect again, autoreply ...) if there is still a
mail.

Is this possible and when how or are there any intentions to implement
something like this?

Regards,
Thoralf Will



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4K7YkT070654 for <[e-mail]>; Tue, 4 Nov 2003 12:07:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4K7YhO070653 for ietf-mta-filters-bks; Tue, 4 Nov 2003 12:07:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4K7XkT070647 for <[e-mail]>; Tue, 4 Nov 2003 12:07:33 -0800 (PST) (envelope-from [e-mail])
Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA4JwvEG028364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2003 14:59:00 -0500
Date: Tue, 04 Nov 2003 15:07:30 -0500
From: Cyrus Daboo <[e-mail]>
To: Madan Ganesh Velayudham <[e-mail]>, [e-mail]
Subject: Re: Fileinto-except
Message-ID: <[e-mail]>
In-Reply-To: <001c01c3a30c$952634f0$3ce62a0f@nt23060>
References:  <001c01c3a30c$952634f0$3ce62a0f@nt23060>
X-Mailer: Mulberry/3.1.0b9 (Linux/PPC)
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 Madan,

--On Wednesday, November 05, 2003 01:18:13 AM +0530 Madan Ganesh Velayudham 
<[e-mail]> wrote:

| 	Please share your views on the attached document.
|
| 	I will submit a draft version after the queue is open.

Is the use of this meant to be to implement some sort of spam/virus 
checking? If so, then I think this is overloading sieve too far - sieve is 
not meant to be an anti-spam/anti-virus tool. Instead you should consider 
using proper tools for that, and hook in the spamtest/virustest extension 
into sieve.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JvUkT070267 for <[e-mail]>; Tue, 4 Nov 2003 11:57:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4JvUkS070266 for ietf-mta-filters-bks; Tue, 4 Nov 2003 11:57:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JvSkT070260 for <[e-mail]>; Tue, 4 Nov 2003 11:57:28 -0800 (PST) (envelope-from [e-mail])
Received: from SCOTTY (unverified [129.215.188.222]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <[e-mail]>; Tue, 4 Nov 2003 19:37:06 +0000
Message-ID: <002b01c3a30b$07af90e0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Madan Ganesh Velayudham" <[e-mail]>
Cc: <[e-mail]>
References: <001101c3a305$f24e0830$3ce62a0f@nt23060>
Subject: Re: Administrator Vs User SIEVE scripts
Date: Tue, 4 Nov 2003 19:37:06 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

> > Actually, it usually needs to be the other way around -- the
> > user needs the ability to override the site's filtering defaults.
>
> I think that that should not be the case. Because if site
> decides
> to reject mails from AAA.com and if user wants to accept, I
> think
> site decision should be the first.

The solution is to have both.  Our Mailserver has a server level script (run
at SMTP level), where your admin could reject mail with a site wide policy.
The end user has no say on the actions in that script.  It also has an end
user sieve script where a user can file mail etc, but if that script takes
no actions, then it will end up in a server defined default mailbox script
that will take some default actions like spamtest/virustest etc.

So the end user can choose to opt out of some of the administrator defined
scripts, and not from others.  That way you put the decision of where to
filter in the hands of the administrator.

Cheers,

Nigel



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JmEkT069777 for <[e-mail]>; Tue, 4 Nov 2003 11:48:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4JmEUN069776 for ietf-mta-filters-bks; Tue, 4 Nov 2003 11:48:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JmCkT069771 for <[e-mail]>; Tue, 4 Nov 2003 11:48:13 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id A8CD41C00F7E for <[e-mail]>; Tue,  4 Nov 2003 11:48:13 -0800 (PST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id BAA04096 for <[e-mail]>; Wed, 5 Nov 2003 01:17:00 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Subject: Fileinto-except
Date: Wed, 5 Nov 2003 01:18:13 +0530
Organization: Hewlett-Packard STSD
Message-ID: <001c01c3a30c$952634f0$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_001D_01C3A33A.AEDE70F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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 a multi-part message in MIME format.

------=_NextPart_000_001D_01C3A33A.AEDE70F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

	Please share your views on the attached document.

	I will submit a draft version after the queue is open.

	Sincerely,
	MG

	**************************
	Madan Ganesh Velayudham
	[e-mail]	
	[phone]
	**************************
	+HP/STSD/Internet Services
	Bangalore, India

	Everything is possible

------=_NextPart_000_001D_01C3A33A.AEDE70F0
Content-Type: text/plain;
	name="madanganeshv-fileinto-except-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="madanganeshv-fileinto-except-00.txt"

	fileinto-except: Removal of attachment from the recieved message
	================================================================
	
	Overview:
	
	SIEVE dont have a mechanism by which it can remove some of 
	the attachment from the message automatically. Some user 
	might want to implement rules like i dont want to reject the 
	message but i dont want to have attachment(s) matching certain 
	criteria.
		
	If the attachment matches the criteria as specified by the user,
	fileinto to the specified mbox expect the specified attachment.
		
	Capability name: fileinto-except
	Capability keywork: fileinto-except
	Capability arguments: N/A
				
	Other issues/ Security considerations in progress....	
		
	Madan Ganesh Velayudham
	Hewlett-Packard
	[e-mail]
	91-80-205-3108
	
	
	
	
	
	
	
------=_NextPart_000_001D_01C3A33A.AEDE70F0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JUHkT069187 for <[e-mail]>; Tue, 4 Nov 2003 11:30:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4JUHUu069185 for ietf-mta-filters-bks; Tue, 4 Nov 2003 11:30:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA4JUEkT069174 for <[e-mail]>; Tue, 4 Nov 2003 11:30:14 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 23666 invoked from network); 4 Nov 2003 14:30:11 -0500
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 4 Nov 2003 14:30:11 -0500
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 10510 invoked by uid 101); 4 Nov 2003 14:30:10 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 4 Nov 2003 14:30:10 -0500
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Administrator Vs User SIEVE scripts
Message-ID: <[e-mail]>
References: <[e-mail]> <001101c3a305$f24e0830$3ce62a0f@nt23060>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001101c3a305$f24e0830$3ce62a0f@nt23060>
User-Agent: Mutt/1.4.1i
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>

> 
> 	I think that that should not be the case. Because if site
> decides 
> 	to reject mails from AAA.com and if user wants to accept, I
> think
> 	site decision should be the first.

That sort of thing sounds like system administrative/political policy
to me.

Especially if we take "reject" as its common non-sieve meaning, where
reject can mean one of SMTP refusal, firewall blackholing, filter
rejection, or any number of things.  At any rate there are some
cases where site policy should precede user decisions, and some
other cases where site policy is applied by default in the
abscense of user decisions.  Facilitating those choices could
be a language issue, but making them: probably not.

mm


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JUHkT069186 for <[e-mail]>; Tue, 4 Nov 2003 11:30:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4JUHxt069184 for ietf-mta-filters-bks; Tue, 4 Nov 2003 11:30:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JUFkT069175 for <[e-mail]>; Tue, 4 Nov 2003 11:30:15 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 04 Nov 2003 11:30:08 -0800 (PST)
Date: Tue, 04 Nov 2003 11:28:08 -0800 (PST)
From: [e-mail]
Subject: RE: Administrator Vs User SIEVE scripts
In-reply-to: "Your message dated Wed, 05 Nov 2003 00:30:42 +0530" <001101c3a305$f24e0830$3ce62a0f@nt23060>
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <001101c3a305$f24e0830$3ce62a0f@nt23060>
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>

> Ned,

> 	Thanks for your reply.

> >
> > > 	I assume all users can have sieve scripts to filter
> > their mails. In
> > > 	addition to user specific sieve scripts, administrator/system
> > > level
> > > 	sieve script should also exist in order to override other user's
> > > scripts.
> >
> > Actually, it usually needs to be the other way around -- the
> > user needs the ability to override the site's filtering defaults.

> 	I think that that should not be the case. Because if site
> decides
> 	to reject mails from AAA.com and if user wants to accept, I
> think
> 	site decision should be the first.

That's not how most of my customer's customers see it. There is far too much
ill-considered automated rejection of email that needs to be able to be able to
be overridden on a per-user basis.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4J0ikT067668 for <[e-mail]>; Tue, 4 Nov 2003 11:00:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4J0idf067667 for ietf-mta-filters-bks; Tue, 4 Nov 2003 11:00:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4J0hkT067662 for <[e-mail]>; Tue, 4 Nov 2003 11:00:43 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id 591FA1C01A87; Tue,  4 Nov 2003 11:00:43 -0800 (PST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id AAA01382; Wed, 5 Nov 2003 00:29:30 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Administrator Vs User SIEVE scripts
Date: Wed, 5 Nov 2003 00:30:42 +0530
Organization: Hewlett-Packard STSD
Message-ID: <001101c3a305$f24e0830$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[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>

Ned,

	Thanks for your reply.

> 
> > 	I assume all users can have sieve scripts to filter 
> their mails. In
> > 	addition to user specific sieve scripts, administrator/system
> > level
> > 	sieve script should also exist in order to override other user's
> > scripts.
> 
> Actually, it usually needs to be the other way around -- the 
> user needs the ability to override the site's filtering defaults.

	I think that that should not be the case. Because if site
decides 
	to reject mails from AAA.com and if user wants to accept, I
think
	site decision should be the first.

> 
> > 	Does any of our SIEVE documents talk about this.
> 
> > 	I guess multiscript draft should capture.
> > 	Pls clarify.
> 
> It is far from clear that we should be getting into 
> classification of scripts as user vs system vs domain vs 
> whatever. This sort of thing is always going to be highly 
> implementation specific.

	I agree. Thanks again.
	
> 
> 				Ned
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4Il3kT067204 for <[e-mail]>; Tue, 4 Nov 2003 10:47:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4Il3Of067203 for ietf-mta-filters-bks; Tue, 4 Nov 2003 10:47:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4Il2kT067189 for <[e-mail]>; Tue, 4 Nov 2003 10:47:02 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 04 Nov 2003 10:47:01 -0800 (PST)
Date: Tue, 04 Nov 2003 10:44:54 -0800 (PST)
From: [e-mail]
Subject: Re: Administrator Vs User SIEVE scripts
In-reply-to: "Your message dated Tue, 04 Nov 2003 23:03:33 +0530" <000001c3a2f9$c59d90a0$3ce62a0f@nt23060>
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <000001c3a2f9$c59d90a0$3ce62a0f@nt23060>
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>

> 	I assume all users can have sieve scripts to filter their mails.
> In
> 	addition to user specific sieve scripts, administrator/system
> level
> 	sieve script should also exist in order to override other user's
> scripts.

Actually, it usually needs to be the other way around -- the user
needs the ability to override the site's filtering defaults.

> 	Does any of our SIEVE documents talk about this.

> 	I guess multiscript draft should capture.
> 	Pls clarify.

It is far from clear that we should be getting into classification
of scripts as user vs system vs domain vs whatever. This sort of thing
is always going to be highly implementation specific.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4HXakT064495 for <[e-mail]>; Tue, 4 Nov 2003 09:33:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4HXagF064494 for ietf-mta-filters-bks; Tue, 4 Nov 2003 09:33:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4HXZkT064489 for <[e-mail]>; Tue, 4 Nov 2003 09:33:35 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel9.hp.com (Postfix) with ESMTP id BC12F1C01C25 for <[e-mail]>; Fri,  7 Nov 2003 20:54:11 -0500 (EST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id XAA26011 for <[e-mail]>; Tue, 4 Nov 2003 23:02:21 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Subject: Administrator Vs User SIEVE scripts
Date: Tue, 4 Nov 2003 23:03:33 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000001c3a2f9$c59d90a0$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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>

	I assume all users can have sieve scripts to filter their mails.
In  
	addition to user specific sieve scripts, administrator/system
level 
	sieve script should also exist in order to override other user's
scripts.

	Does any of our SIEVE documents talk about this. 

	I guess multiscript draft should capture.
	Pls clarify. 

	Cheers,
	MG



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4AM3kT046420 for <[e-mail]>; Tue, 4 Nov 2003 02:22:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4AM39x046419 for ietf-mta-filters-bks; Tue, 4 Nov 2003 02:22:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4AM2kT046414 for <[e-mail]>; Tue, 4 Nov 2003 02:22:02 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id 176BD1C0095F; Tue,  4 Nov 2003 02:22:01 -0800 (PST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA23317; Tue, 4 Nov 2003 15:50:47 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: "'Alexey Melnikov'" <[e-mail]>, <[e-mail]>
Cc: "'Cyrus Daboo'" <[e-mail]>
Subject: RE: SIEVE lunch at IETF?
Date: Tue, 4 Nov 2003 15:52:00 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000001c3a2bd$7ba75b70$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

	I'm more happy to join you all.

	Smiles,
	MG

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> Alexey Melnikov
> Sent: Tuesday, November 04, 2003 3:30 PM
> To: [e-mail]
> Cc: Cyrus Daboo
> Subject: Re: SIEVE lunch at IETF?
> 
> 
> 
> Ken Murchison wrote:
> 
> > Cyrus Daboo wrote:
> >
> >> Can we arrange another SIEVE lunch for anyone who will be 
> at the IETF
> >> next week to discuss on-going SIEVE drafts/issues etc? I would 
> >> tentatively suggest Wednesday lunch - after the IMAPext 
> meeting, on 
> >> the basis that the likely participants would be at IMAPext anyway.
> >
> > I can be available via Jabber.
> 
> I'll try to be available on Jabber as well.
> 
> Alexey
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA49xtkT045645 for <[e-mail]>; Tue, 4 Nov 2003 01:59:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA49xte7045644 for ietf-mta-filters-bks; Tue, 4 Nov 2003 01:59:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA49xmkT045632 for <[e-mail]>; Tue, 4 Nov 2003 01:59:54 -0800 (PST) (envelope-from [e-mail])
Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 4 Nov 2003 10:00:41 +0000
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2003 09:59:42 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Cyrus Daboo <[e-mail]>
Subject: Re: SIEVE lunch at IETF?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Ken Murchison wrote:

> Cyrus Daboo wrote:
>
>> Can we arrange another SIEVE lunch for anyone who will be at the IETF 
>> next week to discuss on-going SIEVE drafts/issues etc? I would 
>> tentatively suggest Wednesday lunch - after the IMAPext meeting, on 
>> the basis that the likely participants would be at IMAPext anyway.
>
> I can be available via Jabber. 

I'll try to be available on Jabber as well.

Alexey




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA40rdkT059477 for <[e-mail]>; Mon, 3 Nov 2003 16:53:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA40rdY9059476 for ietf-mta-filters-bks; Mon, 3 Nov 2003 16:53:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA40rbkT059465 for <[e-mail]>; Mon, 3 Nov 2003 16:53:38 -0800 (PST) (envelope-from [e-mail])
Received: from oceana.com (ny-kenton4d-167.buf.adelphia.net [68.66.168.167]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id hA40rX3w024429; Mon, 3 Nov 2003 19:53:33 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 03 Nov 2003 19:53:33 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031020
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: [e-mail]
Subject: Re: SIEVE lunch at IETF?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Cyrus Daboo wrote:
> 
> Can we arrange another SIEVE lunch for anyone who will be at the IETF 
> next week to discuss on-going SIEVE drafts/issues etc? I would 
> tentatively suggest Wednesday lunch - after the IMAPext meeting, on the 
> basis that the likely participants would be at IMAPext anyway.

I can be available via Jabber.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3NYfkT056628 for <[e-mail]>; Mon, 3 Nov 2003 15:34:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3NYfRX056627 for ietf-mta-filters-bks; Mon, 3 Nov 2003 15:34:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx4.andrew.cmu.edu (MX4.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3NYdkT056622 for <[e-mail]>; Mon, 3 Nov 2003 15:34:40 -0800 (PST) (envelope-from [e-mail])
Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) by mx4.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id hA3NYdWj001659; Mon, 3 Nov 2003 18:34:39 -0500
Date: Mon, 3 Nov 2003 18:34:40 -0500 (EST)
From: Rob Siemborski <[e-mail]>
To: Cyrus Daboo <[e-mail]>
cc: [e-mail]
Subject: Re: SIEVE lunch at IETF?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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 Mon, 3 Nov 2003, Cyrus Daboo wrote:

> Can we arrange another SIEVE lunch for anyone who will be at the IETF next
> week to discuss on-going SIEVE drafts/issues etc? I would tentatively
> suggest Wednesday lunch - after the IMAPext meeting, on the basis that the
> likely participants would be at IMAPext anyway.

I would be very interested in attending another sieve lunch.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [e-mail] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3MOkkT054304 for <[e-mail]>; Mon, 3 Nov 2003 14:24:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3MOkoZ054303 for ietf-mta-filters-bks; Mon, 3 Nov 2003 14:24:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3MOjkT054298 for <[e-mail]>; Mon, 3 Nov 2003 14:24:45 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 03 Nov 2003 14:24:45 -0800 (PST)
Date: Mon, 03 Nov 2003 14:22:44 -0800 (PST)
From: [e-mail]
Subject: Re: SIEVE lunch at IETF?
In-reply-to: "Your message dated Mon, 03 Nov 2003 14:51:48 -0500" <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[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>

> Can we arrange another SIEVE lunch for anyone who will be at the IETF next
> week to discuss on-going SIEVE drafts/issues etc? I would tentatively
> suggest Wednesday lunch - after the IMAPext meeting, on the basis that the
> likely participants would be at IMAPext anyway.

Unfortunately due to my recent medical adventures I won't be attending this
IETF, but I think a sieve lunch would be an excellent idea and I'd be happy to
try and participate remotely via jabber or whatever.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JnZkT048288 for <[e-mail]>; Mon, 3 Nov 2003 11:49:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3JnZVi048287 for ietf-mta-filters-bks; Mon, 3 Nov 2003 11:49:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JnYkT048281 for <[e-mail]>; Mon, 3 Nov 2003 11:49:34 -0800 (PST) (envelope-from [e-mail])
Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA3JfAEG010857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 3 Nov 2003 14:41:10 -0500
Date: Mon, 03 Nov 2003 14:51:48 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: SIEVE lunch at IETF?
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.0b9 (Win32)
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>

Can we arrange another SIEVE lunch for anyone who will be at the IETF next 
week to discuss on-going SIEVE drafts/issues etc? I would tentatively 
suggest Wednesday lunch - after the IMAPext meeting, on the basis that the 
likely participants would be at IMAPext anyway.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3Jk7kT048139 for <[e-mail]>; Mon, 3 Nov 2003 11:46:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3Jk7p2048138 for ietf-mta-filters-bks; Mon, 3 Nov 2003 11:46:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3Jk4kT048132 for <[e-mail]>; Mon, 3 Nov 2003 11:46:06 -0800 (PST) (envelope-from [e-mail])
Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA3JbaEG010750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2003 14:37:36 -0500
Date: Mon, 03 Nov 2003 14:48:13 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail], Madan Ganesh Velayudham <[e-mail]>
cc: [e-mail]
Subject: Re: Does sieve have provisions for examining attachments...
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <000001c3a167$3ef6a200$3ce62a0f@nt23060> <[e-mail]>
X-Mailer: Mulberry/3.1.0b9 (Win32)
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 [e-mail],

--On Sunday, November 02, 2003 11:38 AM -0800 [e-mail] wrote:

|> 	If there is no provision, I would like to
|> 	work on it.
|
| draft-degener-sieve-body-01.txt

That does not allow tests against the MIME structure of a message, only the 
content of a message selected by MIME type. What is needed is an equivalent 
of the "header" test that allows for testing against all MIME headers in a 
message (not just the top-level ones that "header" has access to). I've 
actually been working on a draft of a new "mime" test for that and can post 
it once the draft repository has opened up again. Obviously this requires a 
SIEVE implementation to do a full MIME parse of a message to extract the 
MIME structure, but the body extension pretty much requires that too.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3J6rkT046564 for <[e-mail]>; Mon, 3 Nov 2003 11:06:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3J6raa046563 for ietf-mta-filters-bks; Mon, 3 Nov 2003 11:06:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA3J6qkT046553 for <[e-mail]>; Mon, 3 Nov 2003 11:06:52 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 6442 invoked from network); 3 Nov 2003 14:06:52 -0500
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 3 Nov 2003 14:06:52 -0500
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 27681 invoked by uid 101); 3 Nov 2003 14:06:52 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 3 Nov 2003 14:06:52 -0500
To: "Gu?bj?rn S. Hreinsson" <[e-mail]>
Cc: [e-mail]
Subject: Re: Relay control in SIEVE ???
Message-ID: <[e-mail]>
References: <[e-mail]> <001601c39faf$3ff32b60$3ce62a0f@nt23060> <[e-mail]> <047501c39fce$ca01c9a0$[e-mail]> <[e-mail]> <00b601c3a058$55d49ff0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00b601c3a058$55d49ff0$[e-mail]>
User-Agent: Mutt/1.4.1i
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 Sat, Nov 01, 2003 at 09:12:55AM -0000, Gu?bj?rn S. Hreinsson wrote:
> 
> > sieve (and sieve-like equivalents) can be used for
> > filtering things other than final delivery.  For example, we use
> > sieve filtering here for damping bounces resulting from bad
> > target addresses.  
> 
> Hmmm, I'd be interested in how you do that? Is that something 
> you can share?

We're running qmail, which by default accepts and queues all mail and
then delivers it out of the queue.  (There's a lot of argument about
that behaviour, so probably no need to follow that tangent here.)

When delivery is attempted to a nonexistent user, the default action
is to bounce the message.  It's easy enough to put a delivery filter
on at that point.  We simply apply a sieve (-like) application at
that point, and discard everything that passes a spam test.  Anything
not discarded is bounced.  It's not absolutely perfect but it's
better than the default and significantly reduces our bounce churn.

mm


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3IlwkT045622 for <[e-mail]>; Mon, 3 Nov 2003 10:47:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3IlweJ045621 for ietf-mta-filters-bks; Mon, 3 Nov 2003 10:47:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3IlvkT045616 for <[e-mail]>; Mon, 3 Nov 2003 10:47:58 -0800 (PST) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id hA3Ilv69016636 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Mon, 3 Nov 2003 10:47:57 -0800 (PST)
Received: from jutta.sendmail.com ([10.210.112.12]) by foon.sendmail.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id hA3IluN2025737 for <[e-mail]>; Mon, 3 Nov 2003 10:47:56 -0800
Received: by jutta.sendmail.com (Postfix, from userid 500) id 530C51799D; Mon,  3 Nov 2003 10:47:30 -0800 (PST)
Date: Mon, 3 Nov 2003 10:47:28 -0800
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Message-ID: <[e-mail]>
References: <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9C72Z9yVbgOvWrMZieox/[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9C72Z9yVbgOvWrMZieox/[e-mail]>
User-Agent: Mutt/1.3.24i
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 Sat, Nov 01, 2003 at 10:34:11AM +0100, Arnt Gulbrandsen wrote:
> Jutta Degener writes:
> >I don't think we should describe or limit the behavior of editor 
> >applications at all.
> >
> >One, clients aren't our core competency. We're describing a language, 
> >not the diverse applications that produce scripts written in it.
> 
> An editor parses applications written in it, which is in scope. I agree 
> that the other functions of the editor are out of scope.

I thought we were discussing proscribing how the editor lets
its users enter input that eventually ends up in a field to
the vacation command.  ("Have a separate field to let people
enter the charset for later RFC2047-encoding.")  That's different
from the command syntax itself.

> I think this is worth a sentence or so, making potential high-level 
> editor author aware that they need to parse both utf-8 and 2047-encoded 
> blah.

Yeah, that's reasonable.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3ETpkT035751 for <[e-mail]>; Mon, 3 Nov 2003 06:29:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3ETp8M035750 for ietf-mta-filters-bks; Mon, 3 Nov 2003 06:29:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3ETjkT035743 for <[e-mail]>; Mon, 3 Nov 2003 06:29:46 -0800 (PST) (envelope-from [e-mail])
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id hA3ETf3w003159; Mon, 3 Nov 2003 09:29:41 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 03 Nov 2003 09:32:44 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: number of addresses to
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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:

> Good day!
> 
> Does anybody know if it is possibile to count the number of individual
> addresses in the "to", "cc"  and other recipient fields for ountgoing
> messages to prevent spam!
> 
> The mail server is Suse Openexchage server (postfix, sieve.......)

If the Sieve implementation has support for the relational extension 
(RFC 3431), then you can use the :count match type.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA39YKkT025404 for <[e-mail]>; Mon, 3 Nov 2003 01:34:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA39YKVT025403 for ietf-mta-filters-bks; Mon, 3 Nov 2003 01:34:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from srvwww.sirti.it (srvwww.sirti.it [194.243.146.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA39YDkT025393 for <[e-mail]>; Mon, 3 Nov 2003 01:34:18 -0800 (PST) (envelope-from [e-mail])
Sensitivity: 
Subject: number of addresses to
To: [e-mail]
From: [e-mail]
Date: Mon, 3 Nov 2003 10:33:52 +0100
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on Notesweb/Sirti(Release 5.0.12  |February 13, 2003) at 11/03/2003 10:34:17 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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>

Good day!

Does anybody know if it is possibile to count the number of individual
addresses in the "to", "cc"  and other recipient fields for ountgoing
messages to prevent spam!

The mail server is Suse Openexchage server (postfix, sieve.......)

thanks

maria




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA2MMukT036731 for <[e-mail]>; Sun, 2 Nov 2003 14:22:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA2MMu4I036730 for ietf-mta-filters-bks; Sun, 2 Nov 2003 14:22:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA2MMskT036719 for <[e-mail]>; Sun, 2 Nov 2003 14:22:55 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.0.2] (40.80-202-160.nextgentel.com [80.202.160.40]) by mail.broadpark.no (Postfix) with ESMTP id B960E79217 for <[e-mail]>; Sun,  2 Nov 2003 23:22:44 +0100 (MET)
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <9C72Z9yVbgOvWrMZieox/[e-mail]>
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <9C72Z9yVbgOvWrMZieox/[e-mail]>
Content-Type: text/plain
Organization: 
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 02 Nov 2003 23:22:32 +0100
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 Sat, 2003-11-01 at 10:34, Arnt Gulbrandsen wrote:

> I think this is worth a sentence or so, making potential high-level 
> editor author aware that they need to parse both utf-8 and 2047-encoded 
> blah.

should it?  IMO, that high-level editor should leave it alone, since the
user typed it in explicitly as encoded words for a reason.  but this is
a UI question, really.

it may be a good idea to mention that when the MDA assembles the
vacation message, strings containing only US-ASCII and matching the
encoded word syntax must be left alone rather than being escaped.  this
means that if you want to use a verbatim encoded word as your full name,
you have to either include non-ASCII characters elsewhere, or encode the
string yourself.

-- 
Kjetil T.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA2JcqkT032951 for <[e-mail]>; Sun, 2 Nov 2003 11:38:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA2JcqnB032950 for ietf-mta-filters-bks; Sun, 2 Nov 2003 11:38:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA2JcokT032945 for <[e-mail]>; Sun, 2 Nov 2003 11:38:51 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 02 Nov 2003 11:38:50 -0800 (PST)
Date: Sun, 02 Nov 2003 11:38:41 -0800 (PST)
From: [e-mail]
Subject: Re: Does sieve have provisions for examining attachments...
In-reply-to: "Your message dated Sun, 02 Nov 2003 23:02:09 +0530" <000001c3a167$3ef6a200$3ce62a0f@nt23060>
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <000001c3a167$3ef6a200$3ce62a0f@nt23060>
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,

> 	Does SIEVE have provisions for examining
> 	attachments in the received message ?

> 	like on Windows, I don't want to receive
> 	any exe file attachments. Enforce rules on
> 	attachments.

> 	If there is no provision, I would like to
> 	work on it.

draft-degener-sieve-body-01.txt

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA2HWHkT029507 for <[e-mail]>; Sun, 2 Nov 2003 09:32:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA2HWH36029506 for ietf-mta-filters-bks; Sun, 2 Nov 2003 09:32:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA2HWFkT029501 for <[e-mail]>; Sun, 2 Nov 2003 09:32:15 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel8.hp.com (Postfix) with ESMTP id 39AE91C02D13 for <[e-mail]>; Sun,  2 Nov 2003 12:32:12 -0500 (EST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id XAA19784 for <[e-mail]>; Sun, 2 Nov 2003 23:00:58 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Subject: Does sieve have provisions for examining attachments...
Date: Sun, 2 Nov 2003 23:02:09 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000001c3a167$3ef6a200$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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,

	Does SIEVE have provisions for examining 
	attachments in the received message ?

	like on Windows, I don't want to receive
	any exe file attachments. Enforce rules on
	attachments.

	If there is no provision, I would like to 
	work on it.

	Thanks in advance,

	Cheers,
	MG



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA2AJBkT017383 for <[e-mail]>; Sun, 2 Nov 2003 02:19:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA2AJBx8017382 for ietf-mta-filters-bks; Sun, 2 Nov 2003 02:19:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA2AJ7kT017374 for <[e-mail]>; Sun, 2 Nov 2003 02:19:10 -0800 (PST) (envelope-from [e-mail])
Received: from ls7528 ([192.147.34.142] [192.147.34.142]) by quasar.skima.is with ESMTP; Sun, 2 Nov 2003 10:18:39 Z
Message-Id: <006d01c3a12a$af0d7920$[e-mail]>
From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[e-mail]>
To: "Matthew Elvey \(FM\)" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <052801c39fd4$b2df07f0$[e-mail]> <[e-mail]> <[e-mail]> <00cb01c3a05d$37ef7af0$[e-mail]> <[e-mail]>
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Date: Sun, 2 Nov 2003 10:18:39 -0000
Organization: =?iso-8859-1?Q?S=EDminn?=
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA2AJAkT017378
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>

> >>s/probably/very occasionally/, so it's not as much of an issue.  I think 
> >>a 'refuse' that works perfectly as long as there aren't multiple 
> >>*envelope* recipients (which, keep in mind, is much rarer than multiple 
> >>recipients of any kind) ( and handles the special case by causing an MDN 
> >>to be sent on behalf of the rejecting recipients) is much better than no 
> >>'refuse' at all.
> >>    
> >>
> >
> >Having multiple RCPT TO's is quite common. What you define as much 
> >better is false-positive which for me would be much worse. I would rather 
> >have a filter miss than a false hit. 
> >  
> >
> No, there is no false positive. The non-rejecting recipients get the 
> message.  (The rejecting recipients don't, but that's their intention.  
> Labeling that a false positive 'refuse' isn't correct, no matter how bad 
> the reason for the rejection.)

Forgive me. I though from reading your message that the intention was 
to refuse the whole message (all routing recipients as specified by the 
RCPT TO's) after the message has been "sent" (as by sending the "." 
and CRLF) by sending a "5xx Filtered xxx". 

So to understand this. SIEVE will reject per RCPT TO at the time 
of the RCPT TO? Not later. 

> Multiple RCPT TO's on email that some folks would refuse with Sieve is 
> far from probable, for every user population I can think of, and 
> certainly for all of them considered together, but sure, it happens.
> I think any efficiency lost by restricting multiple RCPT TO would be far 
> outweighed by the efficiencies gained by 'rejecting' spam instead of 
> 'refusing' it.

So you want to perform the above by only having a single RCPT TO 
per submission? Does that include the session? Do you allow RSET? 

> I think the net computer resources used would be reduced, and far more 
> importantly, the net human resources used would be reduced.
> I think there's is zero chance to "modify SMTP" or turn Sieve into a 
> Mieve that can direct every stage of an SMTP session.
> Let us know of any objections you still have to the multiple RCPT TO 
> scheme currently specified by the spec, which is to simply accept the 
> message when at least one RCPT TO wants it, causing no false positives, 
> as discussed above.

Ahh, ok. So a single "positive" for any RCPT TO will outweigh any other 
RCPT TO. So if I have a filter, the filter "hits" on a specific RCPT TO, but 
not on any other RCPT TO, the message is allowed through?

But what's the point then? If this is for catching SPAM messages I think 
they will get the message very quickly and circumwent it...

Furthermore, if you filter on the whole message and then check for the 
RCPT TO's applicability to the filter you are probably wasting a lot of 
resources.

My feeling is there are too many IFs here. This kind of thing needs to be 
analyzed and verified as to what effect it may have on SMTP servers. 


Rgds,
-GSH



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1NMJkT032074 for <[e-mail]>; Sat, 1 Nov 2003 15:22:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1NMJJq032073 for ietf-mta-filters-bks; Sat, 1 Nov 2003 15:22:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA1NMIkT032068 for <[e-mail]>; Sat, 1 Nov 2003 15:22:18 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 18464 invoked from network); 1 Nov 2003 18:22:20 -0500
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 1 Nov 2003 18:22:20 -0500
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 25114 invoked by uid 101); 1 Nov 2003 18:22:19 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Sat, 1 Nov 2003 18:22:19 -0500
To: "Matthew Elvey \(FM\)" <[e-mail]>
Cc: [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <052801c39fd4$b2df07f0$[e-mail]> <[e-mail]> <[e-mail]> <00cb01c3a05d$37ef7af0$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
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 Sat, Nov 01, 2003 at 02:04:36PM -0800, Matthew Elvey (FM) wrote:
> 
> And apologies to Mark - I think I misunderstood what he was 
> communicating and should have been more friendly than I was - especially 
> as I don't want to discourage feedback.

me?  wow, I didn't notice any personal negativity or unfriendliness.
Maybe I'm too dense :-)

mm


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1M4fkT029408 for <[e-mail]>; Sat, 1 Nov 2003 14:04:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1M4fQA029407 for ietf-mta-filters-bks; Sat, 1 Nov 2003 14:04:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1M4ekT029402 for <[e-mail]>; Sat, 1 Nov 2003 14:04:40 -0800 (PST) (envelope-from [e-mail])
X-Sasl-enc: uwlwfDjdfDrim34aKC01DQ 1067724279
Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id C7A473A588E; Sat,  1 Nov 2003 17:04:37 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 01 Nov 2003 14:04:36 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
References: <[e-mail]> <[e-mail]> <052801c39fd4$b2df07f0$[e-mail]> <[e-mail]> <[e-mail]> <00cb01c3a05d$37ef7af0$[e-mail]>
In-Reply-To: <00cb01c3a05d$37ef7af0$[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=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 11/1/2003 1:47 AM, Guðbjörn S. Hreinsson sent forth electrons to convey:
<various folks> said:

>>>>The problem with filtering before storing in the end users mailbox is as Ned
>>>>says, the concept of the mail envelope.  At the SMTP level, the envelope
>>>>probably has many recipients, 
>>>>
>>>>        
>>>>
>>s/probably/very occasionally/, so it's not as much of an issue.  I think 
>>a 'refuse' that works perfectly as long as there aren't multiple 
>>*envelope* recipients (which, keep in mind, is much rarer than multiple 
>>recipients of any kind) ( and handles the special case by causing an MDN 
>>to be sent on behalf of the rejecting recipients) is much better than no 
>>'refuse' at all.
>>    
>>
>
>Having multiple RCPT TO's is quite common. What you define as much 
>better is false-positive which for me would be much worse. I would rather 
>have a filter miss than a false hit. 
>  
>
No, there is no false positive. The non-rejecting recipients get the 
message.  (The rejecting recipients don't, but that's their intention.  
Labeling that a false positive 'refuse' isn't correct, no matter how bad 
the reason for the rejection.)
Multiple RCPT TO's on email that some folks would refuse with Sieve is 
far from probable, for every user population I can think of, and 
certainly for all of them considered together, but sure, it happens.
I think any efficiency lost by restricting multiple RCPT TO would be far 
outweighed by the efficiencies gained by 'rejecting' spam instead of 
'refusing' it.
I think the net computer resources used would be reduced, and far more 
importantly, the net human resources used would be reduced.
I think there's is zero chance to "modify SMTP" or turn Sieve into a 
Mieve that can direct every stage of an SMTP session.
Let us know of any objections you still have to the multiple RCPT TO 
scheme currently specified by the spec, which is to simply accept the 
message when at least one RCPT TO wants it, causing no false positives, 
as discussed above.

>>"Sieve evaluation as typically implemented requires having the entire 
>>message on hand....
>>    
>>
Yes, Cyrus Sieve is likely to stay that way, I'd wager.  But, any Sieve 
script evaluation that doesn't use the (not-yet-standard) body test can 
(potentially, that is it's possible to code any implementation so that 
they) run as soon as the header has been received.

And apologies to Mark - I think I misunderstood what he was 
communicating and should have been more friendly than I was - especially 
as I don't want to discourage feedback.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1I9MkT021093 for <[e-mail]>; Sat, 1 Nov 2003 10:09:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1I9MBi021092 for ietf-mta-filters-bks; Sat, 1 Nov 2003 10:09:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA1I9KkT021085 for <[e-mail]>; Sat, 1 Nov 2003 10:09:20 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 21852 invoked from network); 1 Nov 2003 13:09:21 -0500
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 1 Nov 2003 13:09:21 -0500
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 18732 invoked by uid 101); 1 Nov 2003 13:09:20 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Sat, 1 Nov 2003 13:09:20 -0500
To: "Matthew Elvey \(FM\)" <[e-mail]>
Cc: [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <052801c39fd4$b2df07f0$[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
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>

> >
> >Yeah- what one would need to do is do an attempted delivery for
> >each SMTP "mail to" recipient and deal with rejections based on
> >that attempt.  You would have to have access to each individual's
> >filter program to do this.  Furthermore you would need something
> >other than SMTP, since once you have said "OK" to the "mail to"
> >you can't take it back later. 
> >
> No.  Actually RFC2821 specifies when the server takes responsibility:
> "In sending a positive completion reply to the end of data indication, 
> the receiver takes
> 
>   full responsibility for the message (see section 6.1).'
> Until then, the server can drop the message and connection and be RFC 
> compliant, even if it has said OK to all the recipients.

Only if you ignore the context in which I was making those comments:
i.e. about a message with multiple recipients and about not being
able to selectively reject each recipient after the DATA.


> Also there is no such thing as a "mail to" command; I assume you mean 'rcpt 
> to'.

My apologies, yes that's what I meant.  An embarrassing error, but I
hope people can read through it.  Sorry about that.


> >Here it would be great to have an SMTP
> >enhancement allowing post-DATA rejections.
> > 
> >
> SMTP already allows this.  It's clearly permitted by RFC 2821 to send a 
> negative completion reply to the end of data indication.  Were it not, 
> this I-D would be a non-starter!

Again, I was only talking about post-DATA per-recipient rejection.
Clearly one can reject the entire message after the DATA (that's what
the entire "accept only one recipient" hack comment was based on).

yours,
mm


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1GoDkT018565 for <[e-mail]>; Sat, 1 Nov 2003 08:50:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1GoDkh018564 for ietf-mta-filters-bks; Sat, 1 Nov 2003 08:50:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1Go7kT018558 for <[e-mail]>; Sat, 1 Nov 2003 08:50:08 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 01 Nov 2003 08:50:06 -0800 (PST)
Date: Sat, 01 Nov 2003 08:49:31 -0800 (PST)
From: [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
In-reply-to: "Your message dated Fri, 31 Oct 2003 18:44:17 -0800" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: [e-mail], Arnt Gulbrandsen <[e-mail]>, Jutta Degener <[e-mail]>, Rob Siemborski <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> [e-mail] wrote:

> > I suppose the obvious thing to do would be to let the user edit the
> > charset field separately from the content of the field. But this
> > gets very complex very quickly -- there are lots and lots of charsets
> > and what do you do when they pick a charset that doesn't support all
> > the characters that were specified?
> > Simply allowing access to the raw encoded words in the editor is probably
> > what's going to happen in any case.

> Do you think it's worth noting this as a SHOULD?

I guess that would be OK.

				Ned



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA19lskT000297 for <[e-mail]>; Sat, 1 Nov 2003 01:47:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA19lsmO000296 for ietf-mta-filters-bks; Sat, 1 Nov 2003 01:47:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA19lrkT000290 for <[e-mail]>; Sat, 1 Nov 2003 01:47:53 -0800 (PST) (envelope-from [e-mail])
Received: from ls7528 ([192.147.34.142] [192.147.34.142]) by quasar.skima.is with ESMTP; Sat, 1 Nov 2003 09:47:52 Z
Message-Id: <00cb01c3a05d$37ef7af0$[e-mail]>
From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <052801c39fd4$b2df07f0$[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Date: Sat, 1 Nov 2003 09:47:52 -0000
Organization: =?iso-8859-1?Q?S=EDminn?=
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA19lskT000292
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>

> >>The problem with filtering before storing in the end users mailbox is as Ned
> >>says, the concept of the mail envelope.  At the SMTP level, the envelope
> >>probably has many recipients, 
> >>
> s/probably/very occasionally/, so it's not as much of an issue.  I think 
> a 'refuse' that works perfectly as long as there aren't multiple 
> *envelope* recipients (which, keep in mind, is much rarer than multiple 
> recipients of any kind) ( and handles the special case by causing an MDN 
> to be sent on behalf of the rejecting recipients) is much better than no 
> 'refuse' at all.

Having multiple RCPT TO's is quite common. What you define as much 
better is false-positive which for me would be much worse. I would rather 
have a filter miss than a false hit. 

> "Sieve evaluation as typically implemented requires having the entire 
> message on hand.
> In SMTP this means the only response code that's left is the final one, 
> where the server accepts or rejects the message on behalf of all 
> recipients. This becomes a problem when there are multiple recipients 
> and some reject the message and some do not.  In this case, reject MUST 
> cause an MDN to be sent on behalf of the rejecting recipients. (Idea: 
> allow MTA to tempfail the rejecting recipients and accept the others, 
> until all recipients are rejecting the email; then it can be refused.)"
> [I now reject that latter idea:] Is the additional complexity introduced 
> by specifying how the tempfail would work to make SMTP rejects work even 
> in the relatively rare case of multiple recipients on the envelope 
> really worth it?  Making this mandatory would make the implementation of 
> this spec considerably more work, I think.   I don't want to make it 
> optional, I'd rather leave it out than make it optional.  (By the way, 
> tempfail means to send a 4xx SMTP response code)  It would work as 
> follows:  when there are multiple recipients and some reject the message 
> and some do not, a tempfail response code is sent.  The recipient server 
> has to maintain state about the message so it can recognize it when (if) 
> delivery is reattempted. (some spamware never reattempts delivery!)  
> When delivery is reattempted, the rejecting recipients are tempfailed, 
> but the others aren't.  (This is perfectly acceptable, per RFC2821.) 
> When the third delivery attempt is made, the previously rejecting 
> recipients are not tempfailed and (assuming) all the recipients in this 
> delivery are confirmed to be rejecting recipients, the whole email can 
> be permanently refused.  (Unfortunately, some spamware reattempts 
> delivery even after permanent failures!)  I'd be surprised if a spec 
> requiring this would be broadly implemented, even though I think it 
> would reliably provide the desired result.  I don't want to write a 
> Standards Track document that never gets past the I-D stage!

I'm sorry, I think this is a direction in a very wrong direction. Just to 
wait until you have all the message and the remote MTA states ".CRLF" 
is a very dramatic effort for an MTA. It can turn traumatic since the 
filter may take more than two minutes to finish it's work, especially 
if it's so loaded because it's waiting for 500 ".CRLF"'s before filtering 
on the messages. 

Some MTA's do this though, but they usually are very streamlined for 
just that. They usually also wait for X kbytes before issuing a denial 
or keep accepting the message stream. That may be non-standard but 
implementers are known to turn corners, but I don't think RFC authors 
are allowed to. 

I think it would be better to modify SMTP ti better suit what you want. 
 
> >>so who's configuration do you use?  It's only
> >>when you are about to put a message in a users INBOX will you know that you
> >>can take action on behalf of all the recipients (cos there is only one).

Some messaging environments have local deliver agents that can deliver 
to multiple mailboxes where the message has multiple recipients. It's very 
efficient for the messaging environment, i.e. a 'feature'. 

> >Yeah- what one would need to do is do an attempted delivery for
> >each SMTP "mail to" recipient and deal with rejections based on
> >that attempt.  You would have to have access to each individual's
> >filter program to do this.  Furthermore you would need something
> >other than SMTP, since once you have said "OK" to the "mail to"
> >you can't take it back later. 
> >
> No.  Actually RFC2821 specifies when the server takes responsibility:
> "In sending a positive completion reply to the end of data indication, 
> the receiver takes full responsibility for the message (see section 6.1).'
> Until then, the server can drop the message and connection and be 
> RFC compliant, even if it has said OK to all the recipients.
> Also there is no such thing as a "mail to" command; I assume you mean 'rcpt to'.

I think what the originator of the "mail to" text meant is that after you 
have said "250 recipient <xxx> ok" you can not selectively take that 
statement back. I.e. you can not say later "5xx this recipient blocked 
your message". 

If you drop the connection willfully w/o trying to tell the remote mta that 
you are going to do so then you are not really rfc compliant either, but 
it's a minor offense. But the remote MTA will just go ahead and contact 
you again with the same message, what will you do then? Just keep 
dropping connections?

> >  Or you would have to have a way
> >of enforcing only one recipient per SMTP session.  (accepting
> >the first "mail to" and giving 4xx responses for each subsequent
> >one would be very hackish.)  
> >
> I would be open to something like: an implementation MAY tempfail 
> recipients after the first one to facilitate per-user 'refuse' actions.  
> An implementation could, for example choose to do this for mail from any 
> blacklisted IPs, and safely do so even using aggressive blacklists that 
> list IPs that send both ham and spam.  It's not clear whether this would 
> violate any RFCs.  RFC 2821 does not allow "Rejection of messages (for 
> excessive recipients)" < 100 but a 450 rejection of that sender because 
> the mailbox is unavailable for policy reasons seems acceptable to my 
> reading.

Same thing, you are opening your box up to a lot of connection attempts.
Don't forget, multiple rcpt to's are very efficient (for messages you want 
to receive). It would be a shame to hack it away.

In general, instead of this hacking and SMTP/MTA unfriendly behaviour, 
why not have the SIEVE script/scripts/engine respond to every command 
that is sent to the MTA. The script can then state "pass/fail" or more elaborete 
verdicts to the MTA for each statement. Wouldn't this be easier and more 
SMTP friendly than what is described above?


Rgds,
-GSH



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA19UakT099104 for <[e-mail]>; Sat, 1 Nov 2003 01:30:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA19Uarg099103 for ietf-mta-filters-bks; Sat, 1 Nov 2003 01:30:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA19UZkT099068 for <[e-mail]>; Sat, 1 Nov 2003 01:30:35 -0800 (PST) (envelope-from [e-mail])
Message-Id: <9C72Z9yVbgOvWrMZieox/[e-mail]>
From: Arnt Gulbrandsen <[e-mail]>
To: Jutta Degener <[e-mail]>
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Cc: [e-mail]
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]> <[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
Date: Sat, 1 Nov 2003 10:34:11 +0100
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>

Jutta Degener writes:
> I don't think we should describe or limit the behavior of editor 
> applications at all.
>
> One, clients aren't our core competency. We're describing a language, 
> not the diverse applications that produce scripts written in it.

An editor parses applications written in it, which is in scope. I agree 
that the other functions of the editor are out of scope.

I think this is worth a sentence or so, making potential high-level 
editor author aware that they need to parse both utf-8 and 2047-encoded 
blah.

--Arnt


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA19CvkT093494 for <[e-mail]>; Sat, 1 Nov 2003 01:12:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA19CvME093492 for ietf-mta-filters-bks; Sat, 1 Nov 2003 01:12:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA19CtkT093479 for <[e-mail]>; Sat, 1 Nov 2003 01:12:56 -0800 (PST) (envelope-from [e-mail])
Received: from ls7528 ([192.147.34.142] [192.147.34.142]) by quasar.skima.is with ESMTP; Sat, 1 Nov 2003 09:12:55 Z
Message-Id: <00b601c3a058$55d49ff0$[e-mail]>
From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <001601c39faf$3ff32b60$3ce62a0f@nt23060> <[e-mail]> <047501c39fce$ca01c9a0$[e-mail]> <[e-mail]>
Subject: Re: Relay control in SIEVE ???
Date: Sat, 1 Nov 2003 09:12:55 -0000
Organization: =?iso-8859-1?Q?S=EDminn?=
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA19CukT093485
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>

> But I'm curious about what other MTA filtering you are
> thinking of.  

When you need to service MTA's like sendmail, postfix, exchange, 
lotus notes, acme mta etc. you need to find out or know the specifics 
for that MTA. I can not count the times when a customers tells me 
that a technician has "fixed" the open relay they had, when they in 
fact haven't done so yet. Only to find the techie reach for the manuals 
again.... 

> sieve (and sieve-like equivalents) can be used for
> filtering things other than final delivery.  For example, we use
> sieve filtering here for damping bounces resulting from bad
> target addresses.  

Hmmm, I'd be interested in how you do that? Is that something 
you can share?



Rgds,
-GSH



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA198mkT092238 for <[e-mail]>; Sat, 1 Nov 2003 01:08:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA198muJ092237 for ietf-mta-filters-bks; Sat, 1 Nov 2003 01:08:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA198ikT092201 for <[e-mail]>; Sat, 1 Nov 2003 01:08:47 -0800 (PST) (envelope-from [e-mail])
Received: from ls7528 ([192.147.34.142] [192.147.34.142]) by quasar.skima.is with ESMTP; Sat, 1 Nov 2003 09:08:42 Z
Message-Id: <00ae01c3a057$bed2a2a0$[e-mail]>
From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <001601c39faf$3ff32b60$3ce62a0f@nt23060> <[e-mail]> <047501c39fce$ca01c9a0$[e-mail]> <[e-mail]>
Subject: Re: Relay control in SIEVE ???
Date: Sat, 1 Nov 2003 09:08:41 -0000
Organization: =?iso-8859-1?Q?S=EDminn?=
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA198mkT092230
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>

> Please compare what you have written here with the subject of this thread.
I was pointing out that SIEVE is used and can be successfully used for 
MTA control. Even if I didn't specifically say "relay control" it may apply. 

> Specifying filters that are applicable to more than one user, or applicable
> to all users, is one thing. Specifying filters that control MTA behavior,
> especially behavior as it pertains to detecting and controlling unauthorized
> relay attempts, is quite another.
Filters (SIEVE or not) that control MTA behaviour, including relay control 
are applicable for all users. I can specify filters for attachments of a specific 
user, domain or all users, at the MTA level. But I'm being picky...

> The conflation of sieve with final delivery offers no real impediment to
> performing system level actions.

I think SIEVE or extended SIEVE or a MTA specific filtering language 
derived from SIEVE or not would be a good thing. It may be a pipe dream 
but I think the potential for reducing MTA complexity is there.


Rgds,
-GSH