[Top] [All Lists]

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

2001-10-02 14:03:45

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