Subject: Re: draft-segmuller-sieve-relation-01.txt

From: Wolfgang Segmuller <[email-masked]>
Date: Tue, 02 Oct 2001 17:03:40 -0400

--On Monday, October 01, 2001 5:18 PM -0700 [email-masked] wrote:

> (0) According to RFC 3028, all comparators must be declared in a
>     require clause (section 2.7.3). The only exempt comparators are
>     "i;octet" and "i;ascii-casemap". It isn't entirely clear how this is
>     done, but I assume you'd say something like:
>
>     require "i;ascii-numeric"
>
>     The mechanisms in this document make extensive use of the
> "i;ascii-numeric"     comparator, but none of the examples show it being
> specified in a require     clause.
>
>     I suppose one way around this would be to say that the "relational"
>     extension adds the "i;ascii-numeric" comparator. But this seems
> awkward;     I think it would be better to simply require the comparator
> in your     examples, and maybe note that you have to do this.
>

This was an oversight.  I've updated the documentation to indicate that the 
comparator "i;ascii-numeric" if used would have to be listed in the require 
clause.

>
> (1) This document makes it legal to apply the :count match type to
> envelope     information. But counting the number of MAIL FROM addresses
> is somewhat     nonsensical; there is always exactly one envelope
> originator address     (which can be blank), and RFC 3028 specifies that
> only the RCPT TO     address that the sieve is actually associated with
> is available for     testing. (I say "somewhat nonsensical" because I
> suppose you could use     counting in conjunction with an address part
> argument to test for     missing domain information, blank addresses,
> illegal addresses, and so     on, but there are other ways to do this
> using only facilities in the     base sieve specification.) By talking
> about counting tests on the envelope     this document seems to suggest
> that such tests might apply to all     available RCPT TO addresses. This
> is bad; you'd have a security exposure     if an implementation actually
> did this.
>
>     At a minimum you need to reiterate that only one MAIL FROM and one
>     RCPT TO address are available to the envelope test, so :count is
>     of limited utility in an envelope test.
>

Yes I agree that the envelope part is of limited utility if Sieve is used 
when delivering to the user.  I've added text that indicates that the only 
envelope to you'll see is yourself, and that you will receive at most one 
envelope from.  I also added that if the MAIL FROM is blank, the count will 
be zero.

I would like to keep the envelope part in the spec, because one thought is 
a server wide Sieve script that would see the multiple recipients.  I'll 
add a section in the security concerns about this use.

>
> (2) The ordering operations this document defines are actually specialized
>     string comparisons. They are sufficiently specialized that things like
>     leading zeroes should work correctly. However, negative numbers aren't
>     supported by the "i;ascii-numeric" comparator. Nor is it clear how
> large     an integer needs to be accomodated. Of course you can implement
>     "i;ascii-numeric" using strings, in which case the largest integer
> you'll be able to handle will be quite large. But if you convert to
> 32 bit ints things will be much more limited.
>
>     I'd suggest adding text that says that unsigned 32 int MUST be
> supported     and larger integers MAY be supported. Text pointing out
> that negative     integers aren't handled by "i;ascii-numeric" would also
> be a good idea.
>

I don't recall any discussion about leading zeros.  The leading spaces need 
to be removed for "i;ascii-numeric" to work.  Atleast in my reading of the 
ACAP spec.

I've added text to indicate that "i;ascii-numeric" does not support 
negative numbers, and that 32 bit unsigned int MUST be supported, and 
longer MAY be supported.

>
> (3) Your definition of whitespace differs from that in RFC 2822 in that it
>     includes bare CR and bare LF. This is bad; the definitions need to be
>     aligned. It is already understood that sieve is defined as dealing
>     with messages in canonical form so if bare CRs and LFs appear they
>     will be aberrations and should be treated as such.
>

I've remove the bare CR and bare LF from my definition of whitespace.

>
> (4) In the last part of section 5, you talk about how an RFC 822 compliant
>     message cannot have more than one to or cc field. This is incorrect;
>     RFC 822 explicitly allows multiple to and cc fields but says their
>     meaning is undefined.
>

I've changed the reference to RFC 2822.  RFC 2822 does limit the number of 
to and cc fields to one.

> 					Ned

Wolfgang

---

From: [email-masked]
Date: Tue, 02 Oct 2001 15:46:59 -0700 (PDT)

> add a section in the security concerns about this use.

Ah, but therein lies the problem: The sieve specification quite clearly
states that envelope only operates on the single recipient address the
sieve is associated with.

Short of revising the base sieve specification, this isn't something you're
going to be able to do. And given the security issues I see no chance of
such a revision passing muster.

> to be removed for "i;ascii-numeric" to work.  Atleast in my reading of the

Leading zeroes end up getting ignored, in that the "i;ascii-numeric"
comparator effectively produces an unsigned integer for comparison
purposes.

> negative numbers, and that 32 bit unsigned int MUST be supported, and

That's probably sufficient.

> I've changed the reference to RFC 2822.  RFC 2822 does limit the number of

I meant to suggest this as another perfectly reasonable alternative.

				Ned

---

From: Wolfgang Segmuller <[email-masked]>
Date: Wed, 03 Oct 2001 10:42:19 -0400

--On Tuesday, October 02, 2001 3:46 PM -0700 [email-masked] wrote:

>> I would like to keep the envelope part in the spec, because one thought
>> is a server wide Sieve script that would see the multiple recipients.
>> I'll add a section in the security concerns about this use.
>
> Short of revising the base sieve specification, this isn't something
> you're going to be able to do. And given the security issues I see no
> chance of such a revision passing muster.
>

Ok, I'll remove any reference to server wide Sieve scripts.

What if I add the notation:

With the current Sieve specifications, this extension has limited uses when 
used with the envelope test.  The test for envelope "to" will always return 
1 and the envelope "from" will always return either 0 or 1.

And in the security section:

An implementation MUST ensure that the test for envelope "to" only reflects 
the delivery to the current user.

Wolfgang

---

From: "Nigel Swinson" <[email-masked]>
Date: Wed, 3 Oct 2001 16:17:47 +0100

> the delivery to the current user.

The sieve spec seems to be geared largely at mailbox level filtering, and
sure for a mailbox level filter we should only allow access to 1 recipient,
but for domain or server level filtering perhaps there is application for
the envelope test having access to all the envelope recipients?  There are
several such "tweaks" that you need to do when adapting Sieve to the domain
or server level.  For example "fileinto" is really a "copy to directory" not
a "fileinto mail folder".

Is it really that harmful to put some comment in this spec to say:

A mailbox level implementation MUST ensure that the test for envelope "to"
only reflects the delivery to the current users, but a domain or server
level implementation MAY allow the envelope test to reflect the "to" or
"from" headers to the relevant domain or server.

?

Sieve isn't only useful at the mailbox level after all, it's great as a
server level spam filter too!

Nigel

---

From: [email-masked]
Date: Wed, 03 Oct 2001 08:46:15 -0700 (PDT)

> 1 and the envelope "from" will always return either 0 or 1.

There are two problems with this. One is that it isn't true in the case of
:value; using value tests on both envelope from and to could be useful.
(Remember that the envelope to could include a subaddress.)

The second problem is that it implies that there are 0 or 1 envelope from
addresses. This is incorrect; there is always an envelope from field, which can
be blank.

As I pointed out before, :count probably should return 0 if the envelope from
is blank and you used it with :localpart or :domain. But I don't think it
should return 0 if it is used with :all and the envelope from is blank.

(Actually I don't particularly care how this is resolved as long as the
specification is clear about what should happen.)

Come to think of it, it is possible that an envelope to address is
syntactically invalid as well (lots of implementations support delivery to part
local parts) so I guess it is possible, albeit nonstandard, for :count to
return 0 for an envelope to as well.

How about the following paragraph instead:

  :count has limited uses when used with the envelope test.  In particular,
  this are always exactly one envelope from and envelope to address available
  to be tested.

You might also want to describe how you want the interaction with
:localpart and :domain to work.

> the delivery to the current user.

This ia good addition.

					Ned

---

From: [email-masked]
Date: Wed, 03 Oct 2001 12:22:09 -0700 (PDT)

> the envelope test having access to all the envelope recipients?

Perhaps, but it is currently forbidden.

> There are

Having implemented this, my interpretation is that fileinto isn't a
particularly meaningful action for a higher level sieve to do.

> "from" headers to the relevant domain or server.

Yes, since it directs contradicts the base specification.

> server level spam filter too!

Sure, but it is very debatable how much value access to envelope addresses
adds to such uses.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Wed, 03 Oct 2001 18:35:42 -0400

> particularly meaningful action for a higher level sieve to do.

there are lots of mail servers that do spam filtering that have an
option to file the suspected spam into a mail folder instead of just
deleting it.

	Tony Hansen
	[email-masked]

---

From: [email-masked]
Date: Wed, 03 Oct 2001 15:45:31 -0700 (PDT)

> option to file the suspected spam into a mail folder instead of just

Easily and more generally done using redirect.

				Ned

---

From: "Nigel Swinson" <[email-masked]>
Date: Thu, 4 Oct 2001 00:13:00 +0100

> Easily and more generally done using redirect.

The policy I adopted is fileinto will copy to local directory, and redirect
will forward to a mail address for possible list archive style archiving.
Both have their uses.  Seems like the most natural mapping to me.  Are you
suggesting that this approach is uncommon, unusual or incorrect.  I'd be
keen to hear why as I might need to do some urgent coding...

Nigel

---

From: [email-masked]
Date: Wed, 03 Oct 2001 16:30:53 -0700 (PDT)

> keen to hear why as I might need to do some urgent coding...

The primary issue for me is that fileinto information is qualified by the user
the sieve is associated with, whereas redirect has no such qualification. What
you are saying in effect is that in your implementation fileinto at a server or
domain level is qualified by the server or domain. I'd rather use
redirect to establish the necessary context.

As for legitimacty, I don't believe that's prohibited by the sieve
specification. OTOH, it certainly isn't something that the specification
describes doing.

				Ned

---

From: Wolfgang Segmuller <[email-masked]>
Date: Fri, 05 Oct 2001 11:00:49 -0400

--On Wednesday, October 03, 2001 8:46 AM -0700 [email-masked] wrote:

>   :count has limited uses when used with the envelope test.  In
> particular,   this are always exactly one envelope from and envelope to
> address available   to be tested.
>

How about:

When used with ":count", ":localpart", ":domain", and ":all" are ignored. 
If the entire address is null, the count for that address will be zero, 
otherwise the count is one.

:count has limited uses when used with the envelope test.  In particular, 
there is always exactly one envelope to and at most one for envelope from.

Wolfgang

---

From: [email-masked]
Date: Fri, 05 Oct 2001 13:54:42 -0700 (PDT)

> otherwise the count is one.

Works for me.

				Ned

---

From: Amos Gouaux <[email-masked]>
Date: Tue, 16 Oct 2001 10:02:59 -0500

>>>>> On Wed, 03 Oct 2001 18:35:42 -0400,
>>>>> Tony Hansen <[email-masked]> (th) writes:

th> there are lots of mail servers that do spam filtering that have an
th> option to file the suspected spam into a mail folder instead of just
th> deleting it.

Why couldn't the MTA flag such spam with the addition of a special
header?  Then the user's sieve script could just use a successful
match on this magic header to file the spam into a special folder.
You could cook up an application that generates this magic rule for
the user.

-- 
Amos

---

From: Tony Hansen <[email-masked]>
Date: Tue, 16 Oct 2001 17:30:56 -0400

There are lots of ways of getting to the same place.

	Tony Hansen
	[email-masked]

> You could cook up an application that generates this magic rule for

Date: Tue, 16 Oct 2001 17:30:56 -0400
From: Tony Hansen <[email-masked]>
To: Amos Gouaux <[email-masked]>
CC: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
Sender: [email-masked]

There are lots of ways of getting to the same place.

	Tony Hansen
	[email-masked]

> You could cook up an application that generates this magic rule for

To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
From: Amos Gouaux <[email-masked]>
Date: Tue, 16 Oct 2001 10:02:59 -0500
Lines: 15
Sender: [email-masked]

-- 
Amos

Date: Fri, 05 Oct 2001 13:54:42 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
To: Wolfgang Segmuller <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Works for me.

				Ned

Date: Fri, 05 Oct 2001 11:00:49 -0400
From: Wolfgang Segmuller <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
Sender: [email-masked]

How about:

Wolfgang

Date: Wed, 03 Oct 2001 16:30:53 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
To: Nigel Swinson <[email-masked]>
Cc: [email-masked], Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>, "Tony Hansen" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-segmuller-sieve-relation-01.txt
Date: Thu, 4 Oct 2001 00:13:00 +0100
Sender: [email-masked]

Nigel

Date: Wed, 03 Oct 2001 15:45:31 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

				Ned

Date: Wed, 03 Oct 2001 18:35:42 -0400
From: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
Sender: [email-masked]

	Tony Hansen
	[email-masked]

Date: Wed, 03 Oct 2001 12:22:09 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
To: Nigel Swinson <[email-masked]>
Cc: Wolfgang Segmuller <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

Date: Wed, 03 Oct 2001 08:46:15 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
To: Wolfgang Segmuller <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

This ia good addition.

					Ned

From: "Nigel Swinson" <[email-masked]>
To: "Wolfgang Segmuller" <[email-masked]>, <[email-masked]>
Subject: Re: draft-segmuller-sieve-relation-01.txt
Date: Wed, 3 Oct 2001 16:17:47 +0100
Sender: [email-masked]

?

Nigel

Date: Wed, 03 Oct 2001 10:42:19 -0400
From: Wolfgang Segmuller <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
Sender: [email-masked]

Wolfgang

Date: Tue, 02 Oct 2001 15:46:59 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
To: Wolfgang Segmuller <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

				Ned

Date: Tue, 02 Oct 2001 17:03:40 -0400
From: Wolfgang Segmuller <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
Sender: [email-masked]

Wolfgang