Re: Mailing lists: in/out/ban sets.

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Michelle Dick
Fecha:  
A: exim-users
Asunto: Re: Mailing lists: in/out/ban sets.
Rich wrote:
>
> I agree completely, which is why I'm not doing mailing list management
> with Exim. I'm doing mailing list EXPLOSION, which Exim does very
> efficiently and elegantly. List management (changing the population
> of the input and output sets in accordance with user requests) is done
> by a completely separate agency.


Although, mailing list programs are moving to the situation where the
output set varies with every single mailing and is dependent on the
content of that mailing (trivial example: allowing members to specify
whether they recieve copies of their own postings). Thus, the
explosion itself is mailing list dependent on things an MTA can't
know.

> Yes, good stuff, but I'm talking about Exim's MTA role, not about list
> management. I haven't tried SmartList but I'm sure it would do the
> job, as indeed would Majordomo and lots of other systems. I know that
> they also provide exploders for plugging into /etc/aliases, but that
> is quite a separate part of the list system, a part that is not needed
> with Exim because it already has an elegant exploder in the form of the
> forwardfile director. It lacks an input set validator at present, but
> that would be so simple to implement and so consistent with Exim's very
> nice set-oriented validation system that it deserves a bit of thought
> put into it to turn it into possibly the nicest implementation of the
> in/out-set concept I've ever seen.


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. If you use an MTA for this function you
eliminate the possibility of processing rejects to add information for
the maintainer and/or poster and constrain yourself on where this
bounce is sent. 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. And
how exact a match has to be is set by the list maintainer. I doubt
Philip is interested in writing fuzzy matching for exim. 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'm not saying that what you want wouldn't be a nice feature for exim,
just that it even if implemented, it still wouldn't even be enough to
do list posting restriction RIGHT. Of course, if your needs are
simple and your list is small enough not to worry about load on the
list maintainer, it might be enough for you.

Regarding other comments: As for having an -outgoing alias. I think
the best solution (if you are going to use outgoing alias at all) is
to have the outgoing alias listed only in a second config file and
have the MLM call exim with this second config. 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).

-- 
Michelle Dick             artemis@???              East Palo Alto, CA