Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today]

From: Bron Gondwana <[email-masked]>
Date: Thu, 04 Jan 2018 12:08:14 +1100

On Fri, 17 Nov 2017, at 09:06, Stan Kalisch wrote:
> 
> Hi,
> 
> On Nov 15, 2017, at 3:30 AM, Bron Gondwana
> <[email-masked]> wrote:>> *There is an open question for this one:*
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/
>> 
>> Ned Freed objected to supporting :fcc for the REJECT action because
>> it allows the sieve server to "lie" about whether it's keeping a copy
>> of the message.  There was debate about whether we should stop people
>> lying at this level, especially since a mail flow could take a copy
>> of every single email before it reached sieve.> 
> I haven't been able to watch any video of the meeting yet, but would
> it be fair to say the main points of this debate were laid out in this
> thread on the Sieve mailing list earlier this year?> 
> https://www.ietf.org/mail-archive/web/sieve/current/msg05362.html
> 

I don't know if this was ever resolved.  I prefer the user to be allowed
to lie, Ned objects to that.  I don't actually care that much though, so
I'm happy to say no :fcc on REJECT.  It's not like I would actually use
it because sieve REJECT is bad anyway, it creates backscatter.
So Ken - I'm happy to go ahead with "not supported on reject".

The other open issue was separate capability string.  I don't think
that's necessary, and nobody else seems to have commented on it.
I've created one task for each:

https://github.com/ietfextra/tracking/issues/14
https://github.com/ietfextra/tracking/issues/15

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Ned Freed <[email-masked]>
Date: Thu, 04 Jan 2018 07:17:55 -0800 (PST)

> >> of every single email before it reached sieve.>

That's true but beside the point. Making service-level copies of messages is
one thing, giving users a direct way to conveniently say "I didn't get this
message" when they actually did is quite another.

> > https://www.ietf.org/mail-archive/web/sieve/current/msg05362.html

I would have thought so, but since the point that service-level
copying of messages made above is still deemed relevant, apparently not.

> to lie, Ned objects to that.

Very strongly.

> I don't actually care that much though, so

Not if it's properly implemented around delivery time and at the SMTP level.
(LMTP level is too late.) Perhap this is the key point - it's one thing to
cause a DSN to be sent saying "this message was never delivered" when in fact
it was. It's quite another to send a MDN saying "I threw this message away."

The latter carries no implication the message wasn't read and the content
possibly retained by the user in some way. The former does carry such an
implication.

And sure enough, if you check RFC 8098 you'll find that the disposition types
allowed in an MDN are "displayed", "deleted", "dispatched", and "processed". 
(If the sieve reject action uses an MDN it's required to set the type to
"deleted".) "delivery failed" is conspicuous by it's absence.

> So Ken - I'm happy to go ahead with "not supported on reject".

The alternative is to require an MDN be used in this case. Which of course
creates a possible source of backscatter.

> that's necessary, and nobody else seems to have commented on it.

Certainly not if :fcc only applies to vacation. However, if it applies
to reject in a way that forces that extension to behave in a way some
people find undesirable, things get a little more tricky.

> https://github.com/ietfextra/tracking/issues/15

Can you apply :fcc to a notify action that generates an email message? If
not why not?

And for that matter, can you apply :fcc to a notify action that generates some
other kind of notification that could be mapped to an email?

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 4 Jan 2018 15:47:42 +0000

Ned Freed writes:
> Making service-level copies of messages is

Sieve is used for both service-level and user-level scripts, right?

Arnt

---

From: Ken Murchison <[email-masked]>
Date: Thu, 4 Jan 2018 10:58:10 -0500

> creates a possible source of backscatter.

My current plan is to disallow :fcc with reject, unless someone feels 
this needs more discussion.

> people find undesirable, things get a little more tricky.

Agreed.  If we exclude :fcc use with reject, are we comfortable having 
just one capability that covers :fcc use with both vacation and notify?

> other kind of notification that could be mapped to an email?

I had planned on adding text specifically mentioning that :fcc could be 
used with email notifications.

I'm open to allowing it to be used with any notification action.  My 
initial thought would be to state that the mapping of the non-email 
notification content to an RFC5322 formatted message is implementation 
specific.  Do we feel the need to define strict mappings for all known 
notification methods?

-- 
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd

---

From: Ned Freed <[email-masked]>
Date: Thu, 04 Jan 2018 09:25:01 -0800 (PST)

> Sieve is used for both service-level and user-level scripts, right?

And mailing list level. And head of household level. And spam filter level.
Lots of levels.

And multiple scripts can be active at once. See for example:

  https://tools.ietf.org/html/draft-degener-sieve-multiscript-00

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 4 Jan 2018 19:07:50 +0100

Right. I feel that the main disconnect here is that the reject/fcc 
combination may cause one party (the site/company/...) to make a false 
representation about delivery on the instructions of another (the 
addressee).

When those two are the same, this is okayish. Lying on my 
own accord is not pretty, but it is better than lying because someone 
else told me to.

The right answer may be that reject/fcc should be 
available only when the mta owner and the script owner are the same. Or 
that may be unwarranted complexity, and the right answer is to cater to 
one of the two cases and knowingly disregard the other.

Arnt

---

From: Stan Kalisch <[email-masked]>
Date: Thu, 4 Jan 2018 14:40:36 -0500

> message" when they actually did is quite another.

Perhaps, but, after all, reject already provides that facility.  But that's not the central point of my argument in favor of allowing reject to invoke :fcc.

Some users have arguably (at least, certainly morally) legitimate reasons to lie about the delivery of mail.  The users who first come to my mind are survivors of domestic violence and/or sexual assault.  Google surely had in mind stalking and harassment when it provided Google Voice a mechanism to lie about whether or not someone had placed a call to a user's valid phone number.  Granted, backscatter, MDN, DSN, etc., of course, aren't even peripheral considerations in rolling out something like that for phone calls.  But, again, we're only talking about :fcc; reject's ship has already sailed.

I acknowledge your point that "delivery failed" is conspicuous by virtue of the fact that it is missing from RFC 8098.  And I can't say that this gives me no pause of any kind.  But it still seems to me, when you look at both the technical and very real human considerations, that this effort is more trouble than it's worth—I'm having a hard time believing adding :fcc to reject is substantially going to increase reject's (mis)use.  So this strikes me as something that, in effect, merely serves as a lecture to users who may lie, but 1) are not necessarily sanguine or happy about lying, and 2) may actually have the need to lie.  That is a scenario that is not implausible at all.  It is a privacy issue.  I don't want to *encourage* users to lie, but, on the other hand, I don't think the technical arguments are strong enough for the IETF to dictate that a language does or does not deal with such problems.  That should really be entrusted to users and administrators.  Some things, in the end, have to be entrusted to the community.

Thanks,
Stan

> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 4 Jan 2018 21:33:26 +0000

Stan Kalisch writes:
> Perhaps, but, after all, reject already provides that facility. 
>  But that's not the central point of my argument in favor of 
> allowing reject to invoke :fcc.
>
> Some users have arguably (at least, certainly morally) 
> legitimate reasons to lie about the delivery of mail.

You can also argue that software has a duty to serve its user.

If the user wants to send mail claiming that 2+2=7 on Tuesdays, that the 
check is in the mail, or that he/she hadn't received that other mail, 
that's the user's business. The software's duty is to serve its master.

(But as I said in another message, sieve may serve two masters, and even if 
the software will loyally lie in the name of one master, that doesn't mean 
one of the masters should be able to force the software to lie in the name 
of the other.)

Arnt

---

From: Stan Kalisch <[email-masked]>
Date: Thu, 4 Jan 2018 18:34:22 -0500

> On Jan 4, 2018, at 4:33 PM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> Stan Kalisch writes:

I should have been more precise and said "can accommodate" that facility.  As RFC 5429 says:

"Making "reject" compatible with actions that cause mail delivery violates the RFC 5321 [SMTP] principle that a message is either delivered or bounced back to the sender.  So bouncing a message back (rejecting) and delivering it will make the sender believe that the message was not delivered.

"However, there are existing laws requiring certain organizations to archive all received messages, even the rejected ones.  Also, it can be quite useful to save copies of rejected messages for later analysis."

>> But that's not the central point of my argument in favor of allowing reject to invoke :fcc.
>> 
>> Some users have arguably (at least, certainly morally) legitimate reasons to lie about the delivery of mail.
> 
> If the user wants to send mail claiming that 2+2=7 on Tuesdays, that the check is in the mail, or that he/she hadn't received that other mail, that's the user's business. The software's duty is to serve its master.
> 
> (But as I said in another message, sieve may serve two masters, and even if the software will loyally lie in the name of one master, that doesn't mean one of the masters should be able to force the software to lie in the name of the other.)

And as reject already minimally allows a user to do that (lie about the reason a message was rejected), this sounds to me like something that should be left to the discretion of an administrator.  For some systems, the administrator is going to want to give primacy to the user's privacy; for others, the administrator is going to desire to give primacy to accountability to some entity or organization.  To me, this seems like a fair trade-off.  I do concede that's not entirely consistent with RFC 5429's language about archiving leaving the decision up to the "implementation" and that that's something that has to be considered.

Thanks,
Stan

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 05 Jan 2018 10:40:24 +1100

Is everybody OK with having fcc not include reject, and having a
separate capability (fcc-reject or similar) which administrators can
decide whether or not to allow - and indeed, software implementations
the choice whether or not to implement.
That fixes both issues - those who really want the ability to lie can do
so, but it's clear that they're enabling that facility, and it's also
possible for both software vendors and administrators to not provide the
facility in the first place.
Bron.

On Fri, 5 Jan 2018, at 10:34, Stan Kalisch wrote:
> 
>> On Jan 4, 2018, at 4:33 PM, Arnt Gulbrandsen
>> <[email-masked]> wrote:>> 
>> Stan Kalisch writes:
> I should have been more precise and said "can accommodate" that
> facility.  As RFC 5429 says:> 
> "Making "reject" compatible with actions that cause mail delivery
> violates the RFC 5321 [SMTP] principle that a message is either
> delivered or bounced back to the sender.  So bouncing a message back
> (rejecting) and delivering it will make the sender believe that the
> message was not delivered.> 
> "However, there are existing laws requiring certain organizations to
> archive all received messages, even the rejected ones.  Also, it can
> be quite useful to save copies of rejected messages for later
> analysis."> 
>>> But that's not the central point of my argument in favor of allowing
>>> reject to invoke :fcc.>>> 
>>> Some users have arguably (at least, certainly morally) legitimate
>>> reasons to lie about the delivery of mail.>> 
>> If the user wants to send mail claiming that 2+2=7 on Tuesdays, that
>> the check is in the mail, or that he/she hadn't received that other
>> mail, that's the user's business. The software's duty is to serve its
>> master.>> 
>> (But as I said in another message, sieve may serve two masters, and
>> even if the software will loyally lie in the name of one master, that
>> doesn't mean one of the masters should be able to force the software
>> to lie in the name of the other.)> 
> And as reject already minimally allows a user to do that (lie about
> the reason a message was rejected), this sounds to me like something
> that should be left to the discretion of an administrator.  For some
> systems, the administrator is going to want to give primacy to the
> user's privacy; for others, the administrator is going to desire to
> give primacy to accountability to some entity or organization.  To me,
> this seems like a fair trade-off.  I do concede that's not entirely
> consistent with RFC 5429's language about archiving leaving the
> decision up to the "implementation" and that that's something that has
> to be considered.> 
> 
> Thanks,
> Stan
> 
> _________________________________________________
> Extra mailing list
> [email-masked]

---

From: Stan Kalisch <[email-masked]>
Date: Thu, 4 Jan 2018 20:40:41 -0500

> On Jan 4, 2018, at 6:40 PM, Bron Gondwana <[email-masked]> wrote:
> 
> Is everybody OK with having fcc not include reject, and having a separate capability (fcc-reject or similar) which administrators can decide whether or not to allow - and indeed, software implementations the choice whether or not to implement.
> 
> That fixes both issues - those who really want the ability to lie can do so, but it's clear that they're enabling that facility, and it's also possible for both software vendors and administrators to not provide the facility in the first place.

I personally think it should be up to administrators only, but I recognize that's an ugly hack to the spec already in place.  So I'm okay with it.

Thanks,
Stan

---

From: Ned Freed <[email-masked]>
Date: Thu, 04 Jan 2018 21:50:35 -0800 (PST)

> this needs more discussion.

I have no real preference between a mandatory MDN and removing the
capability.

> just one capability that covers :fcc use with both vacation and notify?

Works for me. Vacation and notify are essentially the same code in our
implementation; two capability strings are actually more work.

> specific.  Do we feel the need to define strict mappings for all known

I don't know enough about other methods people have implemented to make
any sort of assessment.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Jan 2018 05:39:34 -0800 (PST)

> the choice whether or not to implement.

Not without the added condition that a MDN MUST be used if :fcc is present.

> facility in the first place.

My issue is that we have no business messing with the meaning of a 5YZ
code in response to a message transder. That cannot be fixed with capabilities.

				Ned

---

From: Stan Kalisch <[email-masked]>
Date: Sun, 7 Jan 2018 15:15:40 -0500

> Not without the added condition that a MDN MUST be used if :fcc is present.

Again, RFC 5429 explicitly mentions messages that have been rejected and then archived.  It does not require MDNs for them.  In fact, the section where it discusses archiving rejected messages refers to both MDNs and DSNs.  How does using :fcc/:fcc-reject meaningfully semantically differ from just chaining fileinto and reject?  The only additional thing you retain is the outgoing rejection message; the original message that was rejected is still (per the requirements of the spec) the same.

> code in response to a message transder.

I think it's a bit hasty to say "messing".  After all, 5YZ codes were adapted over the years for spam.  No one is suggesting to overtly add "stalking" or something like that to the IANA registry.  But why throw the baby out with the bathwater and close the door to a possible future algorithm or procedure that carefully attempts to address at least a subset of these things?

Thanks,
Stan

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Jan 2018 05:42:09 -0800 (PST)

> Some users have arguably (at least, certainly morally) legitimate reasons to
> lie about the delivery of mail.  The users who first come to my mind are
> survivors of domestic violence and/or sexual assault.

I object even more strongly to this justification for adding such a feature.

There are at least two problems here: We haven't even attempted to work through
all the security implications of trying to hide delivery of email. (Rejection
after delivery is another matter entirely, but we're not talking about that
here.)

There are all sorts of ways information can leak and getting this wrong in
matters of life and death is completely unacceptable. (You might start by
thinking about the handling of multi-recipient cases and how you intend to
maintain the privacy of bcc recipients while maintaining a consistent
appearance of the DSNs you send back versus the ones you provide via :fcc.)

Additionally, even if we do all the work to specify this properly, do you think
implementors will get it right? Past experiences says the chances of that are
essentially nil. And a badly implemented system of this sort could cause
exactly the harm it was trying to prevent.

More generally, the business of mail interception for legal/law enforcment
purposes should not be delegated to - let's face it - an obscure feature on an
obscure extension. It's too important for that, and too important to get right.

> Google surely had in
> mind stalking and harassment when it provided Google Voice a mechanism to lie
> about whether or not someone had placed a call to a user's valid phone number. 

This would be more or less equivalent to an MSP providing the means to say
"this is not a valid address" instead  of saying "you're not allowed to send to
this address". Which Sieve reject provides, modulo the ability to use a
5.1.1 response versus a 5.7.x response code. (A feature our implementation
provides for system-level sieves.)

However, a word of caution about side channel risks is once again in order.
5.1.1 no such user responses are typically given to RCPT TO; whereas Sieves
responses come after the message has been transferred. So it may be  possible
to tell when such a mechanism is used.

And let's please not entertain the notion that we can simply ignore
side-channel attacks here. Not to put too fine a point on it, but it seems a
bunch of Intel engineers thought that way back in the 90s, and look where we
are now.

> Granted, backscatter, MDN, DSN, etc., of course, aren't even peripheral
> considerations in rolling out something like that for phone calls.  But, again,
> we're only talking about :fcc; reject's ship has already sailed.

I have no idea what this means.

> I acknowledge your point that "delivery failed" is conspicuous by virtue of the fact that it is missing from RFC 8098.  And I can't say that this gives me no pause of any kind.  But it still seems to me, when you look at both the technical and very real human considerations, that this effort is more trouble than it's worth—I'm having a hard time believing adding :fcc to reject is substantially going to increase reject's (mis)use.  So this strikes me as something that, in effect, merely serves as a lecture to users who may lie, but 1) are not necessarily sanguine or happy about lying, and 2) may actually have the need to lie.  That is a scenario that is not implausible at all.  It is a privacy issue.  I don't want to *encourage* users to lie, but, on the other hand, I don't think the technical arguments are strong enough for the IETF to dictate that a language does or does not deal with such problems.  That should really be entrusted to users and administrators.  Some things, in the end, have to be entru
>  to the community.

And again, I have no objection whatsoever to reject :fcc generating a "deleted"
MDN response. But once again you have the side channel situation to consider -
reject :fcc causing a different response than reject without :fcc also
leaks information.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Jan 2018 06:26:32 -0800 (PST)

> I personally think it should be up to administrators only, but I recognize
> that's an ugly hack to the spec already in place.  So I'm okay with it.

System-level (or if you prefer, administrative) sieve use is not something
our standards cover. They are exclusively focused on user sieves. And you can't 
simply throw in an administrative feature or three willy-nilly without looking
at the whole picture, which turns out to be fairly complicated.

Many years ago Jutta Degener and I proposed working on extending our documents
to cover the system-level case. There was some apetite for that, but
unfortunately the absoltuely appalling handling of sieve base specification
revision by the IESG at the time drained the energy of the group and that, as
they say, was that.

I certainly would not object to work in this area, but I'm skeptical that
there's sufficient interest.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Jan 2018 07:33:03 -0800 (PST)

> representation about delivery on the instructions of another (the

That's part of it, but not the entire story. The main issue is undoubtedly
the ability of a user to get the site as a whole to lie about whether or
mail was delivered to them.

But consider the case of system-level use of reject :fcc. This is also
problematic. For one thing, if this results in a 5YZ response in the SMTP
diaglogue, the :fcc copy is going to differ from the DSN that's sent to the
originator (assuming a DSN is even sent - what about SUBMIT?). So what you
have here is a different form of lying: The administrator (or however
owns the system-level sieve) gets a wholly synthetic DSN that may
differ substantially from what the remote system actually sent.

I suppose you could address this issue by making the action of :fcc conditional
on whether or not a DSN/MDN, on the theory that the point of :fcc is to capture
the DSN/MDN, not the underlying message. 

I also note in passing that it's not a reliable means of capturing the
underlying message, since the DSN/MDN may not include the whole thing. So it's
actually kind of a worst case: You can't be sure that the message is there, but
you also can't assume it isn't.

> one of the two cases and knowingly disregard the other.

I don't think this addresses all the issues. What does appear to me to do so is
to require the use of an MDN for user-level reject :fcc. As for system-level,
I'll again point out that we lack the necessary context for discussing this in
our documents, but if we were to do so I'd say :fcc on a system-level sieve
only provides a copy of the DSN if the system produced one.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Jan 2018 13:21:57 -0800 (PST)

> Again, RFC 5429 explicitly mentions messages that have been rejected and
> then archived.

You're referring to this paragraph:

   However, there are existing laws requiring certain organizations to
   archive all received messages, even the rejected ones.  Also, it can
   be quite useful to save copies of rejected messages for later
   analysis.

This is in reference to legal intercept, compliance archiving, and similar
mechanisms. This has nothing whatsoever to do with giving random users
the means to falsely claim that a message wasn't delivered when in fact
it was.

> It does not require MDNs for them.

Of course it doesn't. In many cases legal intercept requirements call for
the interception to be done invisibly.

> In fact, the section where it discusses archiving rejected messages refers
> to both MDNs and DSNs.  How does using :fcc/:fcc-reject meaningfully
> semantically differ from just chaining fileinto and reject?

See above. One is a tool for users to keep track of the messages sent on their
behalf by sending them a copy of those messages; the other is a tool for
organizations and law enforcement intended to monitor some subset of the
traffic the site receives. Semantically they aren't even close.

I'll also note that the requirements of legal intercept are in general
not met by keeping copies of MDNs and DSNs for rejected messages; in many
if not most cases those MDNs and DSNs do not contain the entire message and
even when they do the message may not be in its original form.

> The only additional thing you retain is the outgoing rejection message; the
> original message that was rejected is still (per the requirements of the spec)
> the same.

The same as what the sieve agent received. Which can be and often is markedly
dissimilar to what came in over the wire. Legal intercept tends to favor
collection of the latter, and may require it.

> I think it's a bit hasty to say "messing".  After all, 5YZ codes were adapted
> over the years for spam

Actually, no. AFAIK the only time RFC 5321 has been updated to add a 5YZ
code is by RFC 7504, which adds 521 and 556:

   521 Host does not accept mail
   556 Domain does not accept mail

Neither of these have anything to do with handling spam.

> No one is suggesting to overtly add "stalking" or
> something like that to the IANA registry.  But why throw the baby out with the
> bathwater and close the door to a possible future algorithm or procedure that
> carefully attempts to address at least a subset of these things?

I have no idea what this is in reference to. I'm only talking about the
handling of reject :fcc here.

				Ned

---

From: Stan Kalisch <[email-masked]>
Date: Sun, 7 Jan 2018 17:57:34 -0500

> after delivery is another matter entirely, but we're not talking about that

Actually, I'm talking about both.

Users can in fact lie about the reason a message triggers, say, a MDN.

> matters of life and death is completely unacceptable.

I am not denying this and couldn't agree more.

> (You might start by
> essentially nil.

My reaction to that is that implementors getting a spec right is *always* a concern of mine.

With regard to the issue of DSNs, I'll concede I'm not aware of what all Sieve implementations do and was somewhat surprised by the text about them in RFC 5429.  (This isn't a criticism; I know that people sometimes do experiments that specs have to attempt to address.)  I do know if I were to write an implementation that integrated DSNs, I would tiptoe toward it for many of the same reasons you describe.

Given that Sieve was designed to act on messages upon delivery, if enough implementors here in the WG aren't interested in the idea of even pursuing anything linking Sieve to DSNs, then it's not of the greatest concern to me if the MDN for :fcc on reject is made mandatory.

> And a badly implemented system of this sort could cause

Of course.

> obscure extension.
> It's too important for that, and too important to get right.
> 
>> Google surely had in
> side-channel attacks here.
> Not to put too fine a point on it, but it seems a

No, I think that's apropos.

> I have no idea what this means.

Again, it's about the fact that reject can accommodate the ability to be used with fileinto, etc, and that reject essentially carries a minimal ability to lie about why a message's disposition has ended up the way it has.

> reject :fcc causing a different response than reject without :fcc also

I haven't looked at Cyrus code in a while, but, presumably, the implementors behind this draft have considered such things.

Thanks,
Stan

---

From: Stan Kalisch <[email-masked]>
Date: Sun, 7 Jan 2018 18:30:37 -0500

> You're referring to this paragraph:

Yes.

> the means to falsely claim that a message wasn't delivered when in fact

"Random users" can do things like archive messages for their own legal counsel (something I've done, actually) or law enforcement while not wanting to read the messages, themselves.

> the interception to be done invisibly.

I only made these comments in response to your assertions that random users find it convenient to get the system to lie.  Etc.

The technical argument is different entirely.

Again, if the argument is the appetite isn't there for further development, then I'm in agreement with your stipulation about the use of MDNs.  Which basically applies to the rest of my comments below.  Most of this discussion has unfortunately been the two of us talking past one another; I think we're basically in agreement.

> traffic the site receives.

Again, a user can retain a subset of communications for, say, legal counsel.

> Semantically they aren't even close.
> 

I should have said "the purposes for which 5YZ codes have been used."

I think we basically agree about careless implementations and security implications.  I don't think we agree on the purposes users have, but that's neither here nor there at this point.  I certainly have no disagreement about your comments about side-channel attacks—I don't think those points can be overstated.

Thanks,
Stan

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 08 Jan 2018 11:05:36 +1100

On Mon, 8 Jan 2018, at 02:33, Ned Freed wrote:
>> combination may cause one party (the site/company/...) to make
>> a false>> representation about delivery on the instructions of another (the
>> addressee).
> 
> That's part of it, but not the entire story. The main issue is
> undoubtedly> the ability of a user to get the site as a whole to lie about
> whether or> mail was delivered to them.
> 
> But consider the case of system-level use of reject :fcc. This is also> problematic. For one thing, if this results in a 5YZ response in
> the SMTP> diaglogue, the :fcc copy is going to differ from the DSN that's
> sent to the> originator (assuming a DSN is even sent - what about SUBMIT?). So
> what you> have here is a different form of lying: The administrator (or however> owns the system-level sieve) gets a wholly synthetic DSN that may
> I suppose you could address this issue by making the action of :fcc
> conditional> on whether or not a DSN/MDN, on the theory that the point of :fcc is
> to capture> the DSN/MDN, not the underlying message.
> 
> I also note in passing that it's not a reliable means of capturing the> underlying message, since the DSN/MDN may not include the whole
> thing. So it's> actually kind of a worst case: You can't be sure that the message is
> there, but> you also can't assume it isn't.
> 
>> own accord is not pretty, but it is better than lying because someone>> else told me to.
> 
>> available only when the mta owner and the script owner are the
>> same. Or>> that may be unwarranted complexity, and the right answer is to
>> cater to>> one of the two cases and knowingly disregard the other.
> 
> I don't think this addresses all the issues. What does appear to me to
> do so is> to require the use of an MDN for user-level reject :fcc. As for
> system-level,> I'll again point out that we lack the necessary context for
> discussing this in> our documents, but if we were to do so I'd say :fcc on a system-
> level sieve> only provides a copy of the DSN if the system produced one.
> 
> Ned

That seems fine to me.  I think there's some confusion about the point
of FCC, and we might need some clarifying text.
FCC in supposed to be a copy of the message that was sent on your
behalf, so if the system didn't generate a message, there's
nothing to store.
Basically, I want to be able to have sieve take a copy of any message it
generates, even if that message includes part of the original text of a
message that wasn't accepted.
Bron.

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Jan 2018 16:15:52 -0800 (PST)

> Actually, I'm talking about both.

I'm not. The situation after delivery is entirely different. Once something
is delivered to a user's mailbox the transport system is no longer involved.

Everything about MDNs is discretionary: generation, content, everything.  Users
and their agents are free to say or do whatever they want. They can send a
"deleted" MDN and keep the message, or send a "dispatched" MDN when in fact
they simply deleted the message.
 
> Users can in fact lie about the reason a message triggers, say, a MDN.

Absolutely. This is expected to be the case. Of course senders can elect to
trust a sender, but if they do this is an arrangement that lies outside the
service architecture the mail system provides.

The transport infrastructure is a different story. We all have to trust it,
and there are enough issues with that already; we should not be adding more.

> Given that Sieve was designed to act on messages upon delivery,

Sorry, that's incorrect. Sieve was designed to operate at some point
around the time of delivery. There are implementations that operate
before, during, or after delivery.

In the specific case of reject, a user agent needs to use MDNs since the
time for the generation of DSNs is past. Something operating at the SMTP
server level should use SMTP status codes if at all possible - and the
specification goes to considerable trouble to make that possible.

This is further complicated by there being two verbs (reject/ereject),
which further complicates matters.

> if enough
> implementors here in the WG aren't interested in the idea of even pursuing
> anything linking Sieve to DSNs, then it's not of the greatest concern to me if
> the MDN for :fcc on reject is made mandatory.

FWIW, our implementation operates at the SMTP server level and uses SMTP
status codes whenever possible. 

> Again, it's about the fact that reject can accommodate the ability to be used
> with fileinto, etc, case.

First, such usage is NOT RECOMMENDED, meaning it should only be done if there's
a really good reason. Second, as the RFC points out, doing this at the SMTP
level is a direct violation of RFC 5321. Call me a stickler if you like, but I
don't think that's a good thing.

Third, it seems clear that the presence of all this text in the RFC is in a
misguided attempt to try and make sieve actions like keep and fileinto somewhat
compatible with legal intercept applications. Unfortunately the entire cant of
Sieve is such that this is basically a fool's journey in user-space sieves, and
as I have pointed out previously, system sieves are beyond the scope of what's
covered in the RFCs.

>  and that reject essentially carries a minimal ability to
> lie about why a message's disposition has ended up the way it has.

This is a result of the range of places where Sieve can be applied. What's
appropriate prior to delivery is different from what's appropriate after
delivery.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 08 Jan 2018 06:05:30 -0800 (PST)

> of FCC, and we might need some clarifying text.

I agree.

> behalf, so if the system didn't generate a message, there's

Exactly. I would suggest changing the Abstract to read something like:

   The Sieve Email Filtering Language provides a number of action commands,
   some of which can generate additional messages on behalf of the user.
   This document defines an extension to such commands to allow a copy of
   any generated reply message to be filed into a target mailbox.

And the Introduction should begin with the same sentence:

   The Sieve Email Filtering Language [RFC5228] provides a number of action
   commands, some of which can generate additional messages on behalf of the
   user.

And conclude with:

   This extension defines a ":fcc" argument to action commands which
   generate additional messages to allow a copy of the reply message to be
   filed into a target mailbox. The ":fcc" argument is a no-op if the
   associated action command does not directly generate an additional
   message.

   The capability string associated with this extension is "fcc".

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 09 Jan 2018 09:22:00 +1100

On Tue, 9 Jan 2018, at 01:05, Ned Freed wrote:
>   The Sieve Email Filtering Language provides a number of action
>   commands,>   some of which can generate additional messages on behalf of
>   the user.>   This document defines an extension to such commands to allow a
>   copy of>   any generated reply message to be filed into a target mailbox.

I would remove the word "reply" from that.  A notify message sent to a
third party isn't a reply, but I'd still want to FCC it.  (e.g. FastMail
used to have a notify feature that allowed you to send a squashed copy
of the message as an SMS to your registered phone).
Otherwise I entirely agree - that text is a lot clearer.  Thanks!

Bron.

---

From: Ned Freed <[email-masked]>
Date: Mon, 08 Jan 2018 14:55:55 -0800 (PST)

> Otherwise I entirely agree - that text is a lot clearer.  Thanks!

Crap, I thought I have removed it. My bad.

				Ned