There seems to
be something illogical here, Randy!
You say:
TF doesn't return ERR_SKIP, mainly because it wasn't originally designed as
a BPlugin.
Then you suggest:
Finally, would I avoid all these problems if I put TF in filteru.plu? I
put it in filterb.plu as it appeared, naively I suspect, to be the
logical place to put it; mainly because TF appeared to be a more
sophisticated product.
I suspect that would make it worse; if SCSMFILTER decided to trash the
message, I don't think it would then call TF to see if it should be deleted.
So which is better TF in filterb or filteru? It seems as if
both have problems!
TF works fine
as either kind of plugin; it's just that there is no special behavior for
a filterb. There never was any intent that anything TF does be applicable
outside of TF; in particular, there was no intent that the pass list (which I
don't think should be used anyway, but that's a different matter) mean
anything other than "TF won't look at this message". Having *no filtering*
whatsoever is something very different.
Now, just to throw
another spanner in the works, it would be very helpful if emails caught by TF
could be forwarded, where appropriate, to their intended recipient with a
message e.g: "If you are not expecting an email from this source, please
take care before you open it." This would be particularly useful for
trashed messages, which have been caught for some reason or other, but appear
to be OK. After all, it's not our role to act as policeman and only pass on
email as we think fit!
That would probably be best as some sort
of tagging option. I'll put it on the wish
list.
Randy.
