Jan-Piet Mens wrote:
> I'm using Exim 4.44 with Dspam 3.5.0. Messages addressed to my users can
> be of the form user@domain or alias@domain, where alias is normally a
> fullname (jane.doe). The dspam router checks availability
> of a service attribute via LDAP for that user to determine if the user
> has opted in for Dspam.
>
> dspam_router:
> no_verify
> condition = "${if and { \
> {!def:h_X-Spam-Flag:} \
> {!def:h_X-FILTER-DSPAM:} \
> {!eq {$received_protocol}{local}} \
> { <= {$message_size}{512k}} \
> {!eq {${lookup ldap {ldaps:///BASEDN?uid?sub?\
> (&(|(mail=${quote_ldap:$local_part@$domain})(alias=${quote_ldap:$local_part}))(service=dspam)) \
> } {$value} {}}\
> } {} } \
> }\
> {1}{0}}"
> headers_add = "X-FILTER-DSPAM: by $primary_hostname on $tod_full"
> driver = accept
> transport = dspam_spamcheck
>
> Unfortunately, at the point of the transport, the value of `%u' can either be
> `userid' or `alias', depending on the $local_part of the message's address.
>
> dspam_spamcheck:
> driver = pipe
> command = "/usr/local/bin/dspam --deliver=innocent,spam --user ${lc:$local_part} -f \
> '$sender_address' -- %u"
> home_directory = "/tmp"
> current_directory = "/tmp"
> user = exim
> group = mail
> log_output = true
> return_fail_output = true
> return_path_add = false
> message_prefix =
> message_suffix =
>
> How can I ensure that the command in the transport is called with the userid as
> retrieved from LDAP (i.e. I always want the userid, even if the message was
> sent to alias@domain) ? I can't think of anything short of using a command= which
> would once again perform the directory search and then launch dspam; that can't
> be right.
Have you checked out the DSPAM docs on building an 'appliance'? You set
your aliases and main username to share the same DSPAM uid. Thus they
all share the same DSPAM dataset.
I'm not sure if your problem is that DSPAM is treating the alias as a
separate DSPAM user or if you need the real address only to be sent to
the Domino server.
M
--
Michael F. Sprague | mfs@???
Partner | System and Network Engineering (SaNE), Inc
use STD::disclaimer;
