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

From: Ned Freed <[email-masked]>
Date: Sat, 09 Jun 2018 17:49:16 -0700 (PDT)

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

---

From: Ken Murchison <[email-masked]>
Date: Sun, 10 Jun 2018 17:47:49 -0400

Thanks for the detailed review Ned.  I will make your suggested changes 
this week.

(Also, thanks for the review of the application/tzif MIME registration).

On 06/09/2018 08:49 PM, Ned Freed wrote:
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Sun, 10 Jun 2018 18:34:33 -0400

> method. If someone wants to write some requirements for tel: and xmpp: that's

So, are you saying that I should remove Section 3.1 or just any mention 
of notification methods other than mailto: ?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ned Freed <[email-masked]>
Date: Sun, 10 Jun 2018 16:01:49 -0700 (PDT)

> of notification methods other than mailto: ?

3.1 is fine as general guidelines for how to map something into a mail
message.

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Fri, 15 Jun 2018 18:45:20 -0400

Hi Nedx

>> > method. If someone wants to write some requirements for tel: and 

Do you have suggestions as to how you would like to see the existing 
text modified?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC