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.
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.
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.
Leading zeroes end up getting ignored, in that the "i;ascii-numeric"
comparator effectively produces an unsigned integer for comparison
purposes.
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.
That's probably sufficient.
> (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.
I meant to suggest this as another perfectly reasonable alternative.
Ned