Mailing lists: in/out/ban sets.

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Dr. Rich Artym
Fecha:  
A: exim-users
Asunto: Mailing lists: in/out/ban sets.
There just *has* to be a better way to do this ... :-)

I'm trying to configure Exim to handle subscriber-only mailing lists
using the clean set-based approach, ie. separate input and output sets
for validation and exploder control. At first glance, Exim should be
able to adapt easily to this model, since it already uses a sort of
set-based approach to validation when it compares domains in directors
against a file or database. It turns out to be darned difficult in
practice though. So far, the only way I've managed to get it to work
(just barely -- error reporting doesn't end up very user-friendly) is
using the following awful hack, using Exim 1.62:


listsmanager:
driver = forwardfile,
domains = "lsearch;/usr/local/exim/local_list_domains",
no_more,
# NASTY HACK LINE FOLLOWS (/tmp must exist, /fail must not exist):
require_files = "${lookup{$sender_address}lsearch{/usr/local/exim/lists/${local_part}-in}{/tmp}{/fail}}";
file = /usr/local/exim/lists/${local_part}-out,
no_check_local_user,
forbid_pipe,
forbid_file,
errors_to = ${local_part}-request@${domain}


What I've done here is to use the only generic director option I could
find that has an expanded string argument and a director-fail action,
and I've done a lookup of $sender_address within file ${local_part}-in
to yield either an existent or a non-existent filepath to control success
or failure of that option. Yes, it's dreadful.

Seeing as subscriber-only mailing lists are becoming more and more
common as spamming becomes more prevalent, perhaps it would be a
good idea to build into Exim a little more direct support for this
kind of operation, and other validations. [Poor Philip. :-)]

I think that the best approach would be a generic one. For any driver,
one could allow arbitrary validation (generic options) using something like:

require "<condition-string>" "<failure-reason-string>"

It's important that all arguments be expanded strings otherwise a
lot of Exim's functionality would be wasted. Actually, why aren't
all Exim string arguments expanded? I could have used the "local_parts"
generic director option to validate against the file ${local_part}-in
if it were an expanded string, and "except_local_parts" to validate
against ${local_part}-ban to implement a blacklist. But the arguments
to those options are not expanded strings so I couldn't, since the
operation hinges on expanding $sender_address for the search.

Comments, queries, suggestions, etc, all welcome.

Regards,

Rich.
-- 
###########  Dr. Rich Artym  ================  PGP public key available
# galacta #  Email   : rich@???         158.152.156.137
# ->demon #  Web     : http://www.galacta.demon.co.uk  - temp page only
# ->ampr  #  AMPR    : rich@g7exm[.uk].ampr.org 44.131.164.1 BBS:GB7MSW
# ->NTS   #  Fun     : Unix, X, TCP/IP, kernel, O-O, C++, SoftEng, Nano
###########  More fun: Regional IP Coordinator Hertfordshire + N.London