Subject: Re: Security review of SIEVE vacation

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 13 Sep 2005 14:45:50 -0400

On Monday, September 12, 2005 07:31:42 PM +0100 Alexey Melnikov 
<[email-masked]> 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

---

From: Tim Showalter <[email-masked]>
Date: Tue, 13 Sep 2005 13:37:31 -0700

Jeff:

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

Not unsurprisingly, I thought about this when writing the ancient 
ancestral versions of the draft.  I assume the first paragraph of 
section 3.5 is sufficient to allow CMU mailers to deduce that 
[email-masked] is "yours" for the purpose of autoresponses.  At 
this point, it becomes a matter of policy.

Tim

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Sep 2005 18:25:06 -0700 (PDT)

> may or may not actually have anything to do with security.

Seens reasonable to me. I'll drop it in the next revision.

> 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 "[email-masked]" 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.

> there are some words missing there.

I'll change this to read "the vacaction action is incompatible with the sieve
reject action".

> be made consistent with each other.

I'll change the earlier reference to say "implementations MUST generate ...
as specified below".

> already covered by RFC3834.

I'll add a note to that effect.

Thanks for the careful review.

				Ned

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 13 Sep 2005 21:48:39 -0400

On Tuesday, September 13, 2005 06:25:06 PM -0700 Ned Freed 
<[email-masked]> wrote:

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

No, but I sort of want to allow them to do it, rather than depending on the 
policies of the mail server operator to match the address forms used 
wherever the user is sending their mail from.

I agree the spec allows implementations to know about extra addresses using 
more or less arbitrary policy.  If the working group feels this is 
sufficient, I'll live with it.

-- Jeff

---

From: Michael Haardt <[email-masked]>
Date: Wed, 14 Sep 2005 10:58:44 +0200

On Tue, Sep 13, 2005 at 06:25:06PM -0700, Ned Freed wrote:
> current

I agree.  If your address is really jhutz+*@*.cmu.edu, that pattern
should be used by vacation, too, without you having to specify it.
In fact it is probably [email-masked] as well and a number different
patterns, if all you have are Sieve wildcard patterns.  Users will mostly
fail to get that right.  I don't want to think about sites with caseful
local parts.

But perhaps section 3.5 is not clear enough:

                                               Implementations are
   assumed to know the user's email address, but users may have
   additional addresses beyond the control of the local mail system.

Ned: Do you refer to that sentence? If so, how about:

                                               Implementations are
   assumed to know the user's email address, including aliases and
   subaddresses, but users may have additional addresses beyond the
   control of the local mail system.

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 14 Sep 2005 10:43:10 +0100

> I'll change this to read "the vacaction action is incompatible with 

Which reminds me: reject is now defined in a separate document and there 
is no reference to it.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Sep 2005 10:00:04 -0400

>>>>> "Michael" == Michael Haardt <[email-masked]> writes:

    Michael> On Tue, Sep 13, 2005 at 06:25:06PM -0700, Ned Freed
    Michael> wrote:
    >> >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.

    Michael> I agree.  If your address is really jhutz+*@*.cmu.edu,
    Michael> that pattern should be used by vacation, too, without you
    Michael> having to specify it.  In fact it is probably
    Michael> [email-masked] as well and a number different patterns,

Jeff's concern is that imap.outsourcemail.com may well know nothing
about CMU's addressing plan.  If outsourcemail.com is affiliated with
Jeff and not with CMU it is unreasonable for them to have out of band
configuration.

That said, the WG may choose not to solve that use case.

---

From: Michael Haardt <[email-masked]>
Date: Thu, 15 Sep 2005 15:03:11 +0200

> Jeff and not with CMU it is unreasonable for them to have out of band

Now I see where the comparator comes in: To describe remote subaddressing
schemes.

That is not going to work, because subaddressing schemes can not be
covered by Sieve without adding a powerful string expression language.
A comparator may suffice to describe the user-separator-detail scheme,
but without regular expressions it already requires a couple patterns.
More elaborate subaddressing schemes may leave regular languages.

> That said, the WG may choose not to solve that use case.

I am afraid that's the only sensible way, but the vacation extension
should probably document this in section 6, security considerations.
Like:

  If mail is forwarded from a site that uses subaddressing, it may
  be impossible to list all recipient addresses with ":addresses".

Michael

---

From: Ned Freed <[email-masked]>
Date: Thu, 15 Sep 2005 10:44:48 -0700 (PDT)

> More elaborate subaddressing schemes may leave regular languages.

Bingo. Over the years I've seen numerous different subaddressing schemes. Only
a couple of days ago I ran into one that was positional - no separator - and I
believe the subaddress came first.

Things might have been different had the IETF published some suggestions
in this area, but the IETF elected not to do so some years back.

>   be impossible to list all recipient addresses with ":addresses".

Seems reasonable. I'll add it unless someone objects.

				Ned

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 15 Sep 2005 16:18:25 -0400

On Thursday, September 15, 2005 10:44:48 AM -0700 Ned Freed 
<[email-masked]> wrote:

> Bingo. Over the years I've seen numerous different subaddressing schemes.
> Only a couple of days ago I ran into one that was positional - no
> separator - and I believe the subaddress came first.
>

I think you can do a lot with multiple patterns using the pattern matching 
we have now.  And certainly a "powerful string expression language" is not 
out of the question -- we have a draft on the table for adding regular 
expression matching to SIEVE (I have some reservations about that, but 
nothing insurmountable).

Still, ading a match operator and comparator would be a significant change, 
and I can understand not wanting to do it.

> Seems reasonable. I'll add it unless someone objects.

This seems fine.  Is "subaddressing" a well-defined term?

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 15 Sep 2005 19:30:35 -0400

> fail to get that right.  I don't want to think about sites with caseful

Along these lines (pretty closely along these lines in fact) I had
suggested that the envelope recipient address that causes the final
delivery, if known, should be one of the "known addresses" for the user.
After all, if delivery is happening, that address is, by implementation,
one that is valid for that user.  Ned had said:

    I have no problem calling out that the current envelope recipient
    address as an additional source of information for this check. I'll
    add text to this effect to the revision.

(in and around
  http://www.imc.org/ietf-mta-filters/mail-archive/msg05948.html
)

and I think that that still addresses some of the concern.  Is that
additional text still pending or was it shot down (I didn't notice if it
was)?

-mm-

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 17 Sep 2005 01:06:44 +0100

> This seems fine.  Is "subaddressing" a well-defined term?

Yes, see draft-ietf-sieve-rfc3598bis-01.txt

---

From: Ned Freed <[email-masked]>
Date: Wed, 21 Sep 2005 08:09:06 -0700 (PDT)

> additional text still pending or was it shot down (I didn't notice if it

Yes, this has been added and will be in the next update.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Fri, 23 Sep 2005 17:52:57 -0700 (PDT)

> Which reminds me: reject is now defined in a separate document and there

FYI, this is fixed in the -03 version.

				Ned