Subject: [Extra] Status of draft-ietf-extra-sieve-fcc

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Jan 2019 16:40:16 +0000

Hi,

Based on IESG review, I think the document should have some text about 
the following security/privacy considerations:

1) Possible information disclosure from generated messages which are 
filed to shared folders (as opposed to private folders). I.e. non 
intended parties might discover that a Sieve script owner is on 
holidays, owner's location, etc.

2) FCC can put owner over quota, causing denial of service.

I don't believe we need to come up with any novel solutions to these 
problems, but we should explain them.

Best Regards,

Alexey

---

From: Ken Murchison <[email-masked]>
Date: Thu, 10 Jan 2019 11:44:33 -0500

> problems, but we should explain them.

3) Should I revert back to the RFC 5228 "fileinto" text about handling 
non-existent ":fcc" mailbox?

-- 

Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Jan 2019 16:45:46 +0000

> non-existent ":fcc" mailbox?
I was talking purely about security considerations. You should do other 
changes to the document as agreed with IESG/on the mailing list.

---

From: Ken Murchison <[email-masked]>
Date: Sun, 13 Jan 2019 10:02:51 -0500

> 2) FCC can put owner over quota, causing denial of service.

How would this cause DoS?  If the FCC would put the user over quota, 
presumably this would be treated as a run-time error, and the incoming 
message would be be stored by an implicit keep.  Or are you just saying 
that the FCC itself is what would be denied?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ned Freed <[email-masked]>
Date: Sun, 13 Jan 2019 07:22:49 -0800 (PST)

> that the FCC itself is what would be denied?

It's not the effect of a single fcc, but rather that fcc can be used to create
an additional stream of messages, the cumulative effect of which would be to
put the user at or over quota.

As for the handling of situations where the fcc can't be delivered, we're
talking about notifications here, and we've learned the hard way that
generating more traffic as as result of a notification delivery failure is a
REALLY bad idea. As such, I would expect an fcc delivery failure to be
silently ignored. That's certainly how my implementation works.

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Sun, 13 Jan 2019 10:42:31 -0500

> put the user at or over quota.

Ahh, yes!  I hadn't thought about that.

> silently ignored. That's certainly how my implementation works.

Should we add text to this effect?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ned Freed <[email-masked]>
Date: Sun, 13 Jan 2019 07:48:26 -0800 (PST)

> Should we add text to this effect?

Good idea.

				Ned