Wietse:
> Agreed. rejecting mail that hits a spamtrap would require a
> flag that is raised before DATA time, and that is tested at
> DATA time.
/dev/rob0:
> I'm still not clear on why a REJECT (or any other valid access(5)
> result, DISCARD included) wouldn't work with a check_policy_service
> lookup at DATA, but I have to defer to Wietse and Noel. I hope either
At DATA time, recipient-based features are undefined for multi-recipient
mail. Such things are beyond what is possible with the built-in
access language.
With the current access language, a policy daemon would have to
maintain state (the afore-mentioned flag) about preceding queries
for the same mail trasaction (the same "instance" attribute) and
then reject mail at DATA time.
Wietse
