In message <Pine.SOL.3.96.970421103612.21632V-100000@???>,
Philip Hazel writes:
> > Rich wrote:
> > > There just *has* to be a better way to do this ... :-)
> >
> > Yes, use a mailing list manager. It isn't reasonable to expect any
> > MTA to be a full-function mailing list manager.
>
> Yes, I agree with that. (Anything to keep down the wish list... :-)
As I replied to Michelle, a mailing list manager manages (ie. changes)
mailing lists, whereas the explosion is done by the MTA. Don't be fooled
by the fact that the exploder code is often supplied as part of the list
management package --- it's still the MTA that invokes it!!! Well, there
is no need for any separate exploder when one is using Exim as the MTA,
because it's got a very nice exploder built in. That's the bit I'm
looking at here, not any of the more complex list management functions.
> I'm probably not awake yet this Monday morning, but I can't quite see
> your point above. If your local part is "abcd", why do you want to
> validate it using "local_parts" against a file called "abcd-in"? That
> will only ever be searched for a single local part, so could only
> usefully contain a single entry, "abcd". I'm afraid I've missed some
> subtlety here...
Yeah, it must be the Monday morning blues, as I'm *not* comparing
$local_parts against ${local_parts}-in, I'm comparing $sender_address
against the contents of that file and using search failure to cause
the following director statement to fail:
require_files = \
"${lookup{$sender_address}lsearch{DIR/${local_part}-in}{/tmp}{/fail}}";
Let me explain the input/output-set concept for mailing lists. The
output set I don't need to explain, as everyone is familiar with
exploders, ie. sets of addresses that determine to where the incoming
items are going to be delivered. The input set is also a set of
addresses, but this determines the originators from which list mail is
allowed to be accepted. Very commonly, the input and output sets are
identical, but this is not universally true. For example, a site may
gateway mail from mailing lists into local newsgroups, and therefore
a remote mailing list may bear several addresses for that site in its
input set (to allow the site's readers to also post to the list) but
only one delivery address for the site in its output set (since only
one copy of the item needs to be delivered to the site's news gateway).
Other similar scenarios abound: for example, people with Internet
access at work and at home might subscribe to a mailing list from
both places so that they can post from both their addresses, but may
want list items delivered only to a single POP3 mailhost so that they
can read it from whichever place they feel like without getting two
copies to increase their infoglut.
Typically then, the input set is a superset of the output set, but
not necessarily. It's actually easiest to handle both sets as if
they were completely unrelated, at least from the MTA's point of view.
Simply validate the sender of incoming list mail against the input set
and reject a prospective list item if its sender does not appear there,
and use the output set in the usual manner to control the exploder.
It's really very simple, and Exim already uses a model that fits very
nicely into such a set-oriented approach. My horrid hack with the
require_files option does implement the required input functionality
of validation against input sets, but not elegantly, and the error
messages that it yields when validation fails are unhelpful. (A more
ambitious implementation might also define other sets, but input and
output sets are the most important by far.)
I hope that this explains it a bit better, Philip. Any thoughts on
that generic failure control mechanism that I mentioned? Exim seems
to be growing lots of special cases but few generic mechanisms. If
you gave us some more generic machinery, it might *reduce* your high
workload as well as making Exim more orthogonal in its configuration.
Cheers,
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
