Subject: SIEVE lunch at IETF?

From: Cyrus Daboo <[email-masked]>
Date: Mon, 03 Nov 2003 14:51:48 -0500

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

---

From: [email-masked]
Date: Mon, 03 Nov 2003 14:22:44 -0800 (PST)

> 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

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 3 Nov 2003 18:34:40 -0500 (EST)

> 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 * [email-masked] * 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-----

---

From: Ken Murchison <[email-masked]>
Date: Mon, 03 Nov 2003 19:53:33 -0500

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 04 Nov 2003 09:59:42 +0000

Ken Murchison wrote:

>> tentatively suggest Wednesday lunch - after the IMAPext meeting, on 
>> the basis that the likely participants would be at IMAPext anyway.
>

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

Alexey

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Tue, 4 Nov 2003 15:52:00 +0530

I'm more happy to join you all.

	Smiles,
	MG

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Alexey Melnikov
> Sent: Tuesday, November 04, 2003 3:30 PM
> To: [email-masked]
> Cc: Cyrus Daboo
> Subject: Re: SIEVE lunch at IETF?
> 
> 
> 
> Ken Murchison wrote:
> 
> > Cyrus Daboo wrote:
> >

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2003 21:23:29 +0000

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

Jabber conference room for Sieve should be "sieve".

Alexey

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 12 Nov 2003 12:42:30 -0500 (EST)

> 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

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Ken Murchison <[email-masked]>
Date: Wed, 12 Nov 2003 13:09:48 -0500

> jabber.org server is not responding, atleast not for us ;)

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

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Sat, 22 Nov 2003 07:29:22 +0530

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Subject: SIEVE Statistics
Date: Sat, 22 Nov 2003 07:29:22 +0530
Importance: Normal
Sender: [email-masked]

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

Date: Tue, 18 Nov 2003 11:53:00 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IETF MTA Filters List <[email-masked]>
Subject: draft-murchison-sieve-regex-07.txt
Sender: [email-masked]

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;
}

Subject: Re: SIEVE lunch summary
From: Kjetil Torgrim Homme <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Thu, 13 Nov 2003 16:45:50 +0100
Sender: [email-masked]

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.

Date: Wed, 12 Nov 2003 21:11:02 -0600
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: SIEVE lunch summary
Sender: [email-masked]

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/[email-masked]/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

Date: Wed, 12 Nov 2003 10:44:06 -0800 (PST)
From: [email-masked]
Subject: Repost of earlier review comments on managesieve
To: [email-masked]
Sender: [email-masked]

Date: Fri, 17 Oct 2003 09:08:41 -0700 (PDT)
From: [email-masked]
Subject: Review comments on draft-martin-managesieve-04.txt
Sender: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Original-recipient: rfc822;[email-masked]
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

Date: Wed, 12 Nov 2003 13:15:04 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: SIEVE Lunch Agenda Suggestions
Sender: [email-masked]

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)?

Date: Wed, 12 Nov 2003 13:09:48 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Rob Siemborski <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SIEVE lunch at IETF?
Sender: [email-masked]

Date: Wed, 12 Nov 2003 12:42:30 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: SIEVE lunch at IETF?
Sender: [email-masked]

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

Date: Tue, 11 Nov 2003 15:02:16 -0600
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: SIEVE Lunch Agenda Suggestions
Sender: [email-masked]

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

Date: Thu, 06 Nov 2003 21:23:29 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: SIEVE lunch at IETF?
Sender: [email-masked]

Alexey

Date: Wed, 05 Nov 2003 15:45:22 +0000
From: Alexey Melnikov <[email-masked]>
To: Thoralf Will <[email-masked]>
CC: [email-masked]
Subject: Re: running a script after a certain delay
Sender: [email-masked]

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 [email-masked] 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
__________________________________________

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Rob Siemborski'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Fileinto-except
Date: Wed, 5 Nov 2003 21:04:26 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

> [mailto:[email-masked]] On Behalf Of Rob 
> Siemborski
> Sent: Wednesday, November 05, 2003 7:57 PM
> To: Madan Ganesh Velayudham
> Cc: [email-masked]
> 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 * 
> [email-masked] * 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-----
> 
> 

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 5 Nov 2003 10:27:48 -0500
To: Thoralf Will <[email-masked]>
Cc: [email-masked]
Subject: Re: running a script after a certain delay
Sender: [email-masked]

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 [email-masked] 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

Date: Wed, 5 Nov 2003 09:26:36 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: [email-masked]
Subject: Re: Fileinto-except
Sender: [email-masked]

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

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>, <[email-masked]>
Subject: RE: Fileinto-except
Date: Wed, 5 Nov 2003 19:30:35 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

Subject: running a script after a certain delay
From: Thoralf Will <[email-masked]>
To: [email-masked]
Organization: CipSoft GmbH
Date: Wed, 05 Nov 2003 13:52:04 +0100
Sender: [email-masked]

Hi all,

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

Example:
Mail from [email-masked] 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

Date: Tue, 04 Nov 2003 15:07:30 -0500
From: Cyrus Daboo <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>, [email-masked]
Subject: Re: Fileinto-except
Sender: [email-masked]

Hi Madan,

--On Wednesday, November 05, 2003 01:18:13 AM +0530 Madan Ganesh Velayudham 
<[email-masked]> 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

From: "Nigel Swinson" <[email-masked]>
To: "Madan Ganesh Velayudham" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Administrator Vs User SIEVE scripts
Date: Tue, 4 Nov 2003 19:37:06 -0000
Sender: [email-masked]

> > 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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Subject: Fileinto-except
Date: Wed, 5 Nov 2003 01:18:13 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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
	[email-masked]	
	+91-80-205-3108
	**************************
	+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
	[email-masked]
	91-80-205-3108

	
	
------=_NextPart_000_001D_01C3A33A.AEDE70F0--

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 4 Nov 2003 14:30:10 -0500
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Administrator Vs User SIEVE scripts
Sender: [email-masked]

> 
> 	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

Date: Tue, 04 Nov 2003 11:28:08 -0800 (PST)
From: [email-masked]
Subject: RE: Administrator Vs User SIEVE scripts
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Administrator Vs User SIEVE scripts
Date: Wed, 5 Nov 2003 00:30:42 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

Date: Tue, 04 Nov 2003 10:44:54 -0800 (PST)
From: [email-masked]
Subject: Re: Administrator Vs User SIEVE scripts
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 	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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Subject: Administrator Vs User SIEVE scripts
Date: Tue, 4 Nov 2003 23:03:33 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

	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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>, <[email-masked]>
Cc: "'Cyrus Daboo'" <[email-masked]>
Subject: RE: SIEVE lunch at IETF?
Date: Tue, 4 Nov 2003 15:52:00 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

	Smiles,
	MG

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

Date: Tue, 04 Nov 2003 09:59:42 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Cyrus Daboo <[email-masked]>
Subject: Re: SIEVE lunch at IETF?
Sender: [email-masked]

Alexey

Date: Mon, 03 Nov 2003 19:53:33 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: SIEVE lunch at IETF?
Sender: [email-masked]

Date: Mon, 3 Nov 2003 18:34:40 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: SIEVE lunch at IETF?
Sender: [email-masked]

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

Date: Mon, 03 Nov 2003 14:22:44 -0800 (PST)
From: [email-masked]
Subject: Re: SIEVE lunch at IETF?
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

				Ned

Date: Mon, 03 Nov 2003 14:51:48 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: SIEVE lunch at IETF?
Sender: [email-masked]

-- 
Cyrus Daboo

Date: Mon, 03 Nov 2003 14:48:13 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Madan Ganesh Velayudham <[email-masked]>
cc: [email-masked]
Subject: Re: Does sieve have provisions for examining attachments...
Sender: [email-masked]

Hi [email-masked],

--On Sunday, November 02, 2003 11:38 AM -0800 [email-masked] 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

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 3 Nov 2003 14:06:52 -0500
To: "Gu?bj?rn S. Hreinsson" <[email-masked]>
Cc: [email-masked]
Subject: Re: Relay control in SIEVE ???
Sender: [email-masked]

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

Date: Mon, 3 Nov 2003 10:47:28 -0800
From: Jutta Degener <[email-masked]>
To: [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

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

Date: Mon, 03 Nov 2003 09:32:44 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: [email-masked]
Subject: Re: number of addresses to
Sender: [email-masked]

[email-masked] 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.

Sensitivity: 
Subject: number of addresses to
To: [email-masked]
From: [email-masked]
Date: Mon, 3 Nov 2003 10:33:52 +0100
Sender: [email-masked]

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

Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Organization: 
Date: 02 Nov 2003 23:22:32 +0100
Sender: [email-masked]

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.

Date: Sun, 02 Nov 2003 11:38:41 -0800 (PST)
From: [email-masked]
Subject: Re: Does sieve have provisions for examining attachments...
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Subject: Does sieve have provisions for examining attachments...
Date: Sun, 2 Nov 2003 23:02:09 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[email-masked]>
To: "Matthew Elvey \(FM\)" <[email-masked]>, <[email-masked]>
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?=
Sender: [email-masked]

> >>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

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 1 Nov 2003 18:22:19 -0500
To: "Matthew Elvey \(FM\)" <[email-masked]>
Cc: [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Sender: [email-masked]

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

Date: Sat, 01 Nov 2003 14:04:36 -0800
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Sender: [email-masked]

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.

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 1 Nov 2003 13:09:20 -0500
To: "Matthew Elvey \(FM\)" <[email-masked]>
Cc: [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Sender: [email-masked]

> >
> >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

Date: Sat, 01 Nov 2003 08:49:31 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
To: Tim Showalter <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, Jutta Degener <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Sender: [email-masked]

> [email-masked] 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

From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[email-masked]>
To: <[email-masked]>
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?=
Sender: [email-masked]

> >>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

From: Arnt Gulbrandsen <[email-masked]>
To: Jutta Degener <[email-masked]>
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Cc: [email-masked]
Date: Sat, 1 Nov 2003 10:34:11 +0100
Sender: [email-masked]

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

From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[email-masked]>
To: <[email-masked]>
Subject: Re: Relay control in SIEVE ???
Date: Sat, 1 Nov 2003 09:12:55 -0000
Organization: =?iso-8859-1?Q?S=EDminn?=
Sender: [email-masked]

> 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

From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[email-masked]>
To: <[email-masked]>
Subject: Re: Relay control in SIEVE ???
Date: Sat, 1 Nov 2003 09:08:41 -0000
Organization: =?iso-8859-1?Q?S=EDminn?=
Sender: [email-masked]

> 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