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

[Stan Kalisch <[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.  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.

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