ietf-mta-filters
[Top] [All Lists]

Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)

2006-07-11 10:50:37

On Tue, Jul 11, 2006 at 07:01:10PM +0200, Kjetil Torgrim Homme wrote:
On Tue, 2006-07-11 at 12:38 -0400, Mark E. Mallett wrote:
Or.. a test that will see if the message is available for examination.
(e.g. via some read-only variable.)

this is just a slight variation of your #1, isn't it?

Yes, but perhaps easier to get drafted, since it's one thing to
introduce a general mode variable with open-ended meanings,
and another to propose a boolean variable with only one
narrow purpose.  It's
   if 'mode == "rcpt_to"'
vs
   if '! have_message'


But really, a problem is that support for RCPT-TO (and other) scripting
probably needs more fleshing out anyway, since RCPT-TO wants to see more
states and more information returned from a script than simply "accept"
or "reject."  To me, this suggests having a separate scripts, or at
least script fragments, for each mode.

what more information?  you want scripts to be able to return 4xx as
well as 2xx and 5xx?

That sort of thing, yep.  Plus extended result codes, which I suppose
could be encoded into the reject/refuse text.

But I was also thinking this:  I've found that I have need for results
that are "maybe"s.  For example, one return might be "I reject this, but
other logic in the implementation can override my decision" vs "I reject
this, and I really mean it."  Or contrarywise, "I'm OK with this, but
the implementation can override me" and other extrapoloations.  There are
other shades in there somewhere too.  There are also things like "I
reject this, but give a 250 now and defer rejecting until DATA time."

A lot of these things could simply be handled by returning more than one
piece of information, but that's one of those things that, as I say,
need fleshing out.  Other people will likely have had other experiences
and other needs as well.  I certainly have more things that I've thought
of but haven't actually needed or implemented yet.

Some (all?) of these may be things that ordinary users aren't going to
want, but scripts aren't always end-user things.

mm

<Prev in Thread] Current Thread [Next in Thread>