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

[Ned Freed <[e-mail]>]

> On Jan 7, 2018, at 8:39 AM, Ned Freed <[e-mail]> 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.
> >
> > 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.

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.

> >> 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.
> >
> > My issue is that we have no business messing with the meaning of a 5YZ
> > 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

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