In message <199704222340.AA02991@???>, Michelle Dick writes:
> The biggest problem with this is how do you then handle the rejects?
> With SmartList, postings that are rejected are flagged as to why and
> sent to the list maintainer. Alternatives are to bounce the message
> back to the poster with an explanation that postings aren't allowed
> from non-subscribers.
That's easy to specify, along the lines I described before:
reason = "not a subscriber",
errors_to = $sender_address, OR errors_to = ${local_part}-owner,
require = "${lookup{$sender_address}lsearch{LISTS/${local_part}-in}}";
That would seem to handle it adequately using capabilities that are
already built into Exim but simply not gathered together properly yet.
Exim's forwardfile director is so powerful that we're 99% of the way
towards having a fully-fledged general list exploder without needing
any additional help at all. And all done very efficiently without
forking external exploder programs.
> Another problem that Smartlist solves, is that people
> often post from addresses that are almost the same (e.g. they contain
> a machine name and this varies). Smartlist does fuzzy matching, not
> strict, which reduces the load on the list maintainer in dealing with
> rejects based on posts from similar but not identical addresses.
We've got regular expressions in Exim, so if only all strings in the
config were expanded and all strings used in matches were allowed to
contain regular expressions then we wouldn't need anything new to be
coded. That's the point I've been trying to make: it's more or less
all there already, but just not made available to us to use. We need
across-the-board consistency not just to make Exim configure easier to
master by presenting fewer special cases, but even more importantly
because it would give Exim much more power than it has now.
> Also, when
> lists start to get large (thousands, tens of thousands), this sort of
> checking gets expensive, CPU-wise. It doesn't make sense to have the
> MTA duplicate this checking when the MLM will do it as a matter of
> course (it has to process the prospective post anyway).
I disagree: Exim has dbm support built in, and expression matching is
quite efficient too. In contrast, spawning an external exploder is
inevitably an expensive operation. The boot is on the other foot, it
seems to me. (And no, the list manager does NOT have to process posts
that are headed for the exploder, but only those going to the management
address, ie. Majordomo or listserv or <list>-request or whatever.)
> This way, only the
> MLM has access to the -outgoing alias. I'm not currently using an
> -outgoing alias at all, I'm using a program that repeatedly calls
> sendmail and feeds it the addresses. Under this method, there is
> absolutely no way that any post can get sent to the list addresses
> without going through the MLM. But, I'll probably be dropping this
> method, since the program I use is substandard and I don't want to
> rewrite it (I'll use the two config file solution to keep the
> -outgoing address limited to use by the MLM).
Aliases? The forwardfile exploder uses its own file to define the
out-set, not system aliases. That is very safe: using in/out sets
in Exim doesn't offer the possibility of anyone exploding through
just the out-set at all, because the director validates the sender
against the in-set before going anywhere near the out-set exploder.
That's a very nice capability we have in Exim. It leaves the list
management to external systems that are activated only rarely when some
change in the in/out sets is required, while doing internally those
things that are easily within its remit to do efficiently and safely.
[I'm not knocking MLMs, just praising Exim's list explosion model.]
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
