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

On Jan 7, 2018, at 4:21 PM, Ned Freed <ned.freed@mrochek.com> wrote:

>> On Jan 7, 2018, at 8:39 AM, Ned Freed <ned.freed@mrochek.com> 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:

Yes.

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

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

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

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.

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

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

> 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

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

> 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
> 
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra