On Monday, September 12, 2005 07:31:42 PM +0100 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
> Jeff, Ned Freed, the author of vacation asked to have the results of
> security review of the vacation draft in writing. If you didn't find any
> issue, can you please acknowledge that.
>
> If you are too busy to do that quickly, can you please let Sam know so
> that he can find another reviewer.
>
> Cyrus and I would like to avoid any security related surprises during
> IETF wide LC.
Section 3.3 says "... Implementations MAY also impose security restructions
on what addresses can be specified in a ":from" parameter...". I'd drop
the word "security" here; such restrictions are a matter of policy which
may or may not actually have anything to do with security.
Seens reasonable to me. I'll drop it in the next revision.
I'm not real wild about the mechansims defined in sections 3.5 and 3.6 to
try to avoid sending vacation messages to places they shouldn't go. They
seem a bit too inflexible for my taste. I won't object on these grounds,
though.
Just as one example, any address with a mailbox name beginning 'jhutz+' or
'jhutz=' and a domain ending in 'cmu.edu' is is probably mine, and if I
used vacation, I'd certainly want it to treat mail sent to any such address
as belonging to me, regardless of the specific host the mail went to or
what, if anything, occurs after the plus. I'd want that even if the mail
server weren't also at CMU, if I ever decided to forward my CMU mail
off-site. One way to deal with this sort of problem would be to allow a
match type and comparator to be specified for the addresses.
This sort of thing really needs to be up to the implementation, and the current
specification specifically allows this (section 3.5 list item 1) You really
don't want to have to require that every user specify complex matching criteria
in every vacation action they write.
In fact if you used our sieve implementation you'd find that any address of the
form "ned+whatever(_at_)mrochek(_dot_)com" is seen as being one of my addresses.
(Actually, this is only the default, the subaddress separator characters are
settable.) I believe our implementation to be fully compliant to the
specification in this regard.
Section 3.7 says "The vacation is incompatible with reject.". I think
there are some words missing there.
I'll change this to read "the vacaction action is incompatible with the sieve
reject action".
Section 3.3 says implementations SHOULD insert "an appropriate default"
subject line. Section 4.3 then mandates a particular form. These should
be made consistent with each other.
I'll change the earlier reference to say "implementations MUST generate ...
as specified below".
I don't believe this document introduces new security issues that are not
already covered by RFC3834.
I'll add a note to that effect.
Thanks for the careful review.
Ned