Re: [lemonade] draft-ietf-lemonade-imap-sieve-00

[Dave Cridland <dave at cridland.net>]

On Wed Dec 21 16:05:52 2005, Barry Leiba wrote:
> Dave Cridland wrote:
> > If Polymer wanted to both answer the message and forward it, 
> > however, it now can't - the act of answering the message has 
> > destroyed it forever. Of course, in fact, it might not have been 
> > destroyed, but Polymer cannot know that.
>
> Sieve scripts are meant to be user-defined things; if the user 
> wants to
> file \Answered messages away, and remove them from her inbox, I 
> think the
> user should be able to do that.
Yes. Out of curiosity, do you think all IMAP clients send the message 
first, then flag as \Answered? Because if they don't, and they happen 
to reference the message after flagging, perhaps via BURL, perhaps 
not, for body parts, things might get a little confused if setting 
\Answered causes the message to be destroyed.


> I suppose what it comes down to is that you're arguing that clients 
> should
> provide that function, and users who want it should choose clients 
> that do.
> And that the function shouldn't be available on the server, through 
> Sieve
> scripts.
Yes, but not because "that function shouldn't be available on the 
server", but because IMAP servers should remain IMAP servers, and I 
honestly think this breaks behaviour, because it allows different 
clients to effectively define arbitrary semantics for flags which the 
server then manages, in potentially confusing ways. I think allowing 
message destruction as a automatic byproduct retrofitted onto FLAG 
changes is opening a container full of worms, let alone a can. I 
really cannot stress this enough.

The APPEND/COPY automatic message destruction is more palatable to 
me, but the only use for it I can actually see is the notion of 
retrofitting complex filtering and searching[1], which in my mind 
would be better handled explicitly, and I think there's at least a 
economy sized can of worms here too. I very much doubt that I'll ever 
be comfortable with this.

To give a concrete example, I actually really like the notion of 
telling a naïve client to store sent items in a folder which has an 
APPEND/COPY Sieve script which relocates the message elsewhere, 
depending on who it's sent to - I think it's a compelling use-case. 
The only problem is that if a client then chooses to assemble the 
message via CATENATE in that folder, quite innocently, then it'll 
never find it again, so in practise a neat hack turns into serious 
breakage. Which is a shame, as I think that's a reasonable thing for 
a client to try doing, and worse, I cannot think of a workaround that 
will interoperate with Lemonade Profile 1 clients.

That's not a "concern", for me, that's a complete showstopper.


> That argument is fine, but for "diverse service environments", 
> where we
> might WANT some of this stuff done on the server.
Automated filing of older messages sounds cool to me. Hence an 
explicit RUNSIEVE command, fully supported by the client.


> When we get down to it, though, this document was written because 
> of the
> need to do notifications, so my thoughts about what else one might 
> do with
> these functions are speculative.  See below.
Sure. In general, I think you're on to something good. I just think 
you're being a little *too* speculative. :-)

Let's just stick with notifications, and optionally flag changes, for 
now at least. I think reject needs a little more thought - I'm not 
convinced it's a good idea. For a start, I realised that the 
sync/non-sync literal problem doesn't even register - a Sieve script 
is likely to want the entire message before deciding to reject it.

Fileinto/discard really do scare the hell out of me.


> > > > I also have a nasty feeling that some clients will take it upon
> > > > themselves to make setting the \Deleted flag instantly expunge 
> > > the
> > > > message.
> > >
> > > This certainly doesn't give them license to do that.
> >
> > That's exactly what it does do. This grants full license to anyone 
> > and everyone to provide their very own favourite semantics for 
> > mailstores.
>
> It does not, and I can't see how you can claim that.  But let's not 
> get
> into an "Is so! / Is not!" match.
Aw. We could do "Oh, yes, it is! / Oh, no, it isn't!" if you're up 
for a bit of Pantomime, it is the season, after all.


> > > Whether this is a good idea or not is something the implementer 
> > > of the
> > > script has to decide.
> > No, it's not. It's up to the one client author who doesn't like a 
> > two phase delete, and sticks an innocuous checkbox marked "Delete 
> > Immediately" somewhere.
>
> Oh, be real: a client author who wants to do that already can, by 
> just
> putting in the checkbox and putting code in that always sends 
> EXPUNGE
> whenever it sets the \Deleted flag.  The IMAP spec is quite clear 
> about
> that being a bad idea, and clients insist on implementing "Trash"
> mailboxes anyway.  This doesn't change anything with respect to 
> THAT.
No, it means that one client author can not only instruct the server 
to change the semantics for them, but impose their views on everybody 
else. That's quite a major change, I think.


> > Okay, so it can lie about the UIDs all the time, breaking
>
> I had thought that UIDPLUS allowed an "I don't know the UID" 
> response;
> as I look again, I see that it doesn't.  OK.
Mark's newer draft does allow ommission of the UIDPLUS responses 
(COPYUID and APPENDUID), but only, IIRC, in the case where the 
mailbox declares itself as having non-sticky UIDs. In principle, I'd 
be fine with dropping the response even so, but there's no method for 
ommitting a single UID, in the case of MULTIAPPEND/COPY.

> > Without meaning to sound arrogant, it doesn't matter a jot what 
> > anyone thinks. Message content in IMAP is immutable. The only way 
> > to allow EditHeader would be to allocate a new UID for the 
> > message, which in turn destroys the cache.
>
> Uh, we ARE assigning new UIDs, and we're NOT changing headers on 
> existing
> messages.  My draft explicitly says that the EditHeader actions are 
> only
> available for NEW MESSAGES, and so only for cause=APPEND and 
> cause=COPY.
You misunderstood, and reading my own writing, I'm not surprised. I 
meant allocate a new UID for the message compared with the one 
generated by the normal APPEND/COPY mechanism and returned by 
UIDPLUS. It doesn't help that I don't think of APPEND as operating on 
a new message - messages are only copied in IMAP, in my mind, 
creation happens outside its scope.


> That said, you've brought up a point that I hadn't considered: that
> clients expect the messages created by APPEND and COPY to be 
> unchanged,

Exactly. Hence where EditHeader is used, the clients see the message 
instantly destroyed, exactly like your fileinto/discard proposals.

[[
1. Searching with Sieve, a imap-sieve hack: Create a fresh mailbox. 
Add a Sieve script which discards messages you don't want on COPY. Go 
through all source mailboxes you fancy, performing COPY 1:*. Finally, 
open the fresh mailbox and see what you find. It's much more powerful 
than the inbuilt IMAP SEARCH, and allows full "virtual scrolling" 
through the results.
]]

Dave.
--
          You see things; and you say "Why?"
  But I dream things that never were; and I say "Why not?"
   - George Bernard Shaw

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade