BISHOP Micha�l <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > > What about a new incoming action "ok-mark" (or ok-log, ok-test, or > > whatever)? It would behave as normal "ok", that is mail would be > > delivered. But additional to that, it would set the X-TMDA-Action > > header in that mail, regardless of the global ACTION_HEADER_INCOMING > > setting. > > > > > In the testing scenerio, one could use ok-mark for all lines in the > > incoming filter, where some testing is wanted. > > I'll leave it to Jason to say yes or no, though I have a vague feeling > he'll say no. ;-) This seems somewhat misplaced, to me. For one, > why would X-TMDA-Action: be needed on only some e-mails? The testing > scenario is identical to ACTION_HEADER_INCOMING=1 and ok for > everything.
Actually, X-TMDA-Action: doesn't quite provide what you need for a good testing scenario. If your filter says 'drop', for example, the mail is gone. You can't review dropped mail! As another example, if the filter says 'bounce', the original message will be marked with an X-TMDA-Action: field but since it won't be delivered, you'll have to go grubbing through pending/ to see the header. One solution to this is to deliver all mail but deliver mail that you eventually plan to 'drop' to a "Dropped" folder, mail that you will bounce to a "Bounced" folder, etc. Then, regardless of the setting of ACTION_HEADER_INCOMING, you can see the results of your rules. Once you're satisfied that everything is working as it should, you can change those delivery rules to really 'drop' or 'bounce' or whatever. As this process represents work for each user who wants to vet their configuration, providing an "approved" way to do it will save significant time. I'm going to tuck away in the back of my head the idea of a "testing" mode. I'm pretty sure it won't be through additional rule actions, though. That's still too much work, to go back and edit the filter. A global configuration setting might work well, though. In the past, while working on the parser, I've had to add some bizarre and ungainly code so that I could see what was happening (and then, of course, remove it before checking in the final version so that all sorts of debugging nonsense wasn't spewing into people's mail logs). I think having a built-in testing feature might also be of benefit to me (or anyone else who works on the parser). Tim _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
