Re: [Extra] Meeting minutes and notes from today

[Bron Gondwana <[e-mail]>]

On Mon, 8 Jan 2018, at 02:33, Ned Freed wrote:
>> 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).
> 
> 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.
> 
>> 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.
> 
> 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.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]