ietf-mta-filters
[Top] [All Lists]

Re: Security review of SIEVE vacation

2005-09-13 11:49:40


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.

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.

Section 3.7 says "The vacation is incompatible with reject.". I think there are some words missing there.

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 don't believe this document introduces new security issues that are not already covered by RFC3834.

-- Jeff


<Prev in Thread] Current Thread [Next in Thread>