--On Monday, October 01, 2001 5:18 PM -0700
ned(_dot_)freed(_at_)mrochek(_dot_)com 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