Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix

[Cyrus Daboo <[e-mail]>]

Hi Matthew,

--On Tuesday, August 10, 2004 11:36 AM -0700 Matthew Elvey 
<[e-mail]> wrote:

>> There was some discussion at the lunch BOF last week about the utility
>> of refuse.
>
> Cool; wish I coulda been there/participated.  Anyone take minutes?
> (edit: I just heard that Alexey has notes he may share.)

The Jabber log is here:

<http://www.xmpp.org/ietf-logs/[e-mail]/2004-08-04.txt>

I will also attempt to write up a brief summary and post to the list in the 
next day or so.

>> There was general consensus among the participants that it would be
>> better to extend reject to allow for SMTP refusal and DSN generation
>> rather than add a new command. Personally I prefer that approach - but
>> the issue needs more discussion on the list.
>>
>> We've probably been over this before, but can you explain in detail
>> why you think a new command is better than extending the behaviour of
>> reject?
>
> So the idea is just a syntax change, yes?

A syntax change and also a relaxation of the requirement that 'reject' must 
generate an MDN. i.e. if 'reject' occurs in an  implementation that runs 
SIEVE during SMTP then that implementation is allowed to do either an SMTP 
error code, DSN or MDN as it feels appropriate. The 'reject' text specified 
by the user would be used for DSN or MDN text, and we would add a new 
optional parameter for the SMTP error code and descriptive error text.

> What's the gist of the argument for the change? I can't think of any
> strong arguments against the change; here are some less strong arguments:

> 1)A normal extension (the current 'refuse') is a cleaner implementation
> in the sense that it's a standard extension - something that's well
> understood, instead of something that makes the base Sieve RFC 'wrong' by
> changing it.

My argument against a new command is that it makes scripts less portable. 
By relaxing the restriction on reject the same script can run efficiently 
on an implementation that runs at SMTP time and one that runs at final 
delivery/LMTP time. It will also make switching between such 
implementations easier as scripts will not have to be changed to gain the 
benefits of SMTP time rejection.

The question is whether there is ever a case where you would care what type 
of reject behaviour is carried out: SMTP error, DSN or MDN. If there is a 
requirement to allow users to explicitly state the type of error that can 
easily be done as a parameter.

> 2)It's already written and debugged.

True, but I don't think switching to 'relaxed' reject would be a 
significant change. I suspect the integration with SMTP is the biggest 
issue.

> Arguments for the change:
> 1)A change won't break anything, according to the URL below.
>
> Have we done something like this (e.g. modify an action to accept a
> special parameter flag) before?

Yes - the copy extension adds a :copy parameter to fileinto and redirect. 
imapflags also extends fileinto and also keep.


-- 
Cyrus Daboo