On Sat, 27 May 2006, Hilko Bengen wrote:
> So far, I see two possible ways of approaching this task:
>
> (1) Contact the mail filter before each corresponding ACL is processed
> and store the result in one or more variables that can then be
> evaluated by the ACLs.
>
> (2) Implement the Milter queries as conditions that may be used by
> ACLs. Responses are made available through status variables, also.
>
> Which approach would be preferable from an administrator's point of
> view in your opinion?
I think (2) is preferable because it is similar to the interfaces to
the existing content scanners, and it allows the administrator to
control whether the milter is called or not. So a new condition like
milter = something
(I'm not familiar with milters, so I don't know what "something" could
be, but I assume there may be some parameter that is useful.) You need
to consider when this should be TRUE and when FALSE. (Note that the spam
condition has an option for forcing TRUE so that the ACL statement
continues.)
> Currently, I don't see a clean way to explicitly use of some mail
> modification actions of the Milter protocol that usually take place
> just before the MTA accepts (or rejects) a message's DATA. Those are
>
> * changing or removing headers
There are Exim functions to add and remove headers (documented for use
in local_scan(), and change = remove + add) so it should be
straightforward, now that we have the add_header modifier, to implement
a remove_header modifier (and if somebody really wants, change_header as
a convenience).
> * adding or removing recipients
Adding recipients can use the receive_add_recipient() function which is
documented for local_scan(). There is also receive_remove_recipient().
These could trivially be called from new ACL modifiers.
> * replacing the body
*That* would be hard to do in a safe manner because of locking
considerations, though perhaps there is a way it could be done.
Philip
--
Philip Hazel, University of Cambridge Computing Service.
