so, if i understand this correctly we have the following receipe for a
- reject can only be by itself and only once (eventualy with stop)
- keep can apear with any action (except reject) several times, and a
move to Inbox (or similar) will be executed once
- discard can apear with any action (except reject maybe) several times
and the result will be a discard only when soley discard actions are present
- fileinto can apear several times with any action (except reject) and a
move to the specified folder will be executed (if a move to the same
folder is specified is not to be treated as an error but a duplicate
move will not be performed)
- redirect can apear several times and with any action (except reject),
the result consisting in redirecting to the specified address only once
(wihtout giving an error if a duplicate reject with the same address apears)
- any action except stop will cancel the implicit keep
Is this any close to what the specification intended?
Nigel Swinson wrote:
I am new to this list so please do not be harsh.
I am doing an
implementation of sieve as described in rfc 3028, without any extensions
other than the ones described there. I have some questions which were
not answered by the rfc:
I had a lot of problems when I was trying to implement the action interactions,
so I have a lot of sympathy for your questions...
- if I have several actions in a block except stop, I accept only
fileinto and keep, and give an error message for any other combination
of 2 or more (like keep, discard or redirect, discard). Is this wrong?
I'm not sure that's wrong per se, but it's more limited than the specification
allows. The only thing which is wrong is reject when used with any other
action, including itself. So it should be possible to specify multiple
redirects, fileintos, several keeps and lots of discards.
- if I have more actions after I filter a message and several tests
are true, such that several command could be executed like keep and
discard, what do I execute?
Discard is a funny one, and a concept you'll need to become very familiar with is "implicit
keep". It's detailed in the RFC in section 2.10.2. The ONLY thing that discard does is to
cancel the implicit keep. It is not a "hard" action. So to illustrate lets do some
discard + keep = keep
discard + fileinto = fileinto
discard + redirect = redirect
discard + reject = reject (however you can argue from 2.10.4 that this should
trigger a runtime error, but it doesn't seem helpful)
discard + discard = discard
If you want a "hard discard" then I recommend you use discard + stop, as this
will prevent any further actions being taken, and providing you haven't already asked to
keep the message then it really will be discarded.
Hope this helps :o)