Subject: Re: [Extra] sieve-fcc next steps

From: Ken Murchison <[email-masked]>
Date: Fri, 3 Aug 2018 11:08:16 -0400

Hi Ned,

I believe all of your comments/suggestions/nits have been addressed in 
the just posted -03 draft.

Do you have some text describing your implementation that you are able 
to contribute to the Implementation Status section of the draft?

On 06/09/2018 08:49 PM, Ned Freed wrote:
> I have now implemented the fcc extension and thus am in a position to
> comment further on the draft.
>
> I first want to note that this was *far* more difficult to implement than I
> expected. There are a number of issues, but the important one in regards to
> standardization is that the extension more less assumes direct mailbox access.
> This is arguably OK for a Sieve implementation that acts after final delivery,
> but that's not how all implementations work. And when you're talking about an
> implementation that operates as part of an SMTP server, you can't just blithely
> start up an IMAP session and do an APPEND. Even if that's technically feasible,
> what if there's an store availability issue or a timeout?
>
> Of course you can create a new queue to address this, but now you're talking
> about an additional thing that needs to be managed, and we like to avoid doing
> that if possible.
>
> The alternative is to use the same mechanism that's used for mailto:
> notifications and vacation messages. In effect, it's adding another recipient.
> But a special sort of recipient - one that has a regular mailbox and
> potentially a special use mailbox, set of IMAP flags, and create flag attached.
>
> Creating a new mechanism for this would have been a pain, but it occurred to me
> that we already have such a mechanism: Sieve. What :fcc effectively does is
> create a message with an associated sieve fileinto action. And that's how
> I ended up implementing it.
>
> And relevance of this to the standard is that thinking of :fcc in terms of it
> being a  fileinto attached to the new message helps nail down the semantics.
> For example, nowhere does the current document define the syntax or semantics
> of the mailbox argument to :fcc. But RFC 5228 section 4.1 does all of this for
> the mailbox argument to fileinto, and I don't see any reason why we shouldn't
> say that the syntax and semantics have to be the same. Ditto for :specialuse,
> :flags, and :create.
>
>> I asked a few weeks ago about progressing both objectid and sieve-fcc.
>> Since objectid is pretty polished now, I'm ready for that to move on.
>> Sieve-fcc has two outstanding questions though:
>> * what to do about message format for notify/enotify fcc
> The specification of the enotify extension itself provides the tools you need
> for this. In particular, section 4 of RFC 5435 defines the valid_notify_method
> test, which can be used to check if a given notification method is supported. I
> see no reason why we can't add an :fcc parameter to this test to check and see
> if the method is both valid and supports :fcc.
>
> :fcc in this case could be defined to take an argument that would also be
> validated. Alternately, the argument could be omitted and the test could simply
> be for :fcc support, but I see no reason to do that.
>
>> * do we need separate capabilities, or just "fcc"?
> No. Again, the necessary capabilities are there in the extension; all you need
> to do is use them.
>
>> I am soliciting opinions, either "I agree with you, Bron, sounds great"
>> - or  suggestions for better ideas!  I have no strong attachment to any
>> particular choice, but I would like to get this document progressed...
>> * Regarding message format for notify - I'm happy to say "it's up to the
>>    server to serialise something in MESSAGE/RFC822 which is readable and
>>    contains the details of the notification.  Since notify can be
>>    arbitrary data formats, the alternative of trying to specify a
>>    particular behaviour beyond that is either very complex, or very
>>    limiting.  I see no need to lock down the format, since this feature
>>    will be either for a human to read, or for audit/compliance reasons,
>>    so requirements will vary by site.
> Not sufficient IMO. I think that for standardized notification methods we need
> to specify the mapping to an email message.
>
>> * Regarding capability: I'm happy with just fcc - it should be easy to
>>    implement across all types in our server, and I assume in other
>>    servers too.
> Whereas I can readily envision implementing a notification method
> that doesn't translate well if at all to an email message.
>
>> Please let us know what you think.  I'll ask Ken to get it written up
>> and maybe we can get this one processed before Montreal as well.
>> Cheers,
> Here are some specific comments on the current document.
>
> Section 1. The decision to limit the extension to just vacation and
> notify needs to be reflected in the introduction. I suggest changing it to
> read:
>
>     The Sieve Email Filtering Language [RFC5228] provides a number of
>     action commands, some of which can generate additional messages on
>     behalf of the user. It is sometimes desirable to have an archive of the
>     messages generated by such commands.
>
>     This extension defines a new optional tagged argument ":fcc" that
>     can be specified on action commands which generate additional messages to
>     allow a copy of the generated message to be filed into a target mailbox.
>
>     The capability string associated with this extension is "fcc".
>
>     Each action that generates additional messages will need to specify
>     how it interfacts with :fcc. This document also specifies the interaction
>     of :fcc with the  Vacation [RFC5230] and Notify [RFC5435] extensions.
>
> Section 2. There's been pushback to use the updated keyword text in RFC 8174
> rather than RFC 2119. Might as well make the change now.
>
> Section 3. This should state that the syntax and semantics MUST match those
> of the mailbox arugment to fileinto specified in RFC 5228 section 4.1.
>
> Section 3.3. I suggest that for now this be made specific to the mailto:
> method. If someone wants to write some requirements for tel: and xmpp: that's
> fine too.
>
> Section 3.4. Given that this document only specifies use of :fcc with vacation
> and notify, and given the content of 3.5, I'm not sure we really need this. I
> think it would be best to remove it. If we do retain it, it needs to be recast
> along the lines of "Implementations MUST NOT allow use of :fcc with ereject and
> reject.
>
> Section 3.6 needs to state that when fileinto arguments are used with :fcc
> they have the same syntax and semantics as they do with fileinto.
>
> That's it for now.
>
> 				Ned
>
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC