Re: [exim] using exim to reject prohibited mail to Mailman l…

On Mon, Jul 03, 2006 at 05:19:00PM +0100, Tony Finch wrote:
> On Mon, 3 Jul 2006, Chris Lightfoot wrote:
> >
> > More generally this has got me wondering about how much of a
> > mailing-list manager could be implemented within a modern MTA. It is
> > painfully obvious that most of Mailman's queueing and aliasing stuff
> > could equally well be implemented with Exim and a database and suitable
> > transports. More difficult is what to do with the moderation queue
> > aspect of the problem, which is required in some mailing lists.
>
> Yes, the coupling between transport, database, and user interface is one
> of the nastier aspects of Mailman's architecture.
>
> Exim isn't quite studly enough to do all the things that Mailman offers,
> in particular attachment policies and general MIME mangling. If Exim were
> to have full support for SMTP extensions like 8BITMIME, BINARYMIME, and
> UTF8SMTP, it would have to have a MIME parsing and mangling
> infrastructure, and so fancy MLM stuff would be less of a problem to
> implement.

ok. This sort of functionality could be done at present,
by tagging messages with information about the required
processing steps at the ACL stage (either in the acl_m*
variables or in a header added at SMTP time) and then
processing them in a transport filter (or a local scan
function, though I see that modifying the message at this
stage is discouraged). That's not very nice, but then none
of this plumbing ever is, really....

... that said, doing all of the necessary processing in an
ACL could become a little bit unwieldy. It would be useful
to be able to call some arbitrary external code from an
ACL without the fork-and-exec cost and with something
slightly more convenient than the UNIX socket read/write
interface. How about a general `pass message and envelope
to some external process over [authenticated] HTTP, get
response status and content' string expansion function?
That's a bit nasty, I admit, but (I argue) no more so than
the package-specific protocols for ClamAV, SpamAssassin,
etc....

> For the moderation queue, probably the best way would be to deliver the
> messages into an IMAP mailbox, which could be accessed by the MLM front
> end using the usual webmail techniques. The MLM could even re-submit
> moderated messages for transport using BURL (RFC 4468). Then your user
> interface, transport, storage, and database infrastructure can be cleanly
> separated using open protocols.

noted -- I hadn't started to think about the mechanics of
moderation yet.

I remain (idly) interested in whether it is possible to
exploit SMTP-time error-reporting to do moderation without
ever having to send a `your message has been held' or a
`your message has been rejected' bounce back to the poster
/ spammer. I suspect the solution I outlined is too ugly
to be very popular, though.

> Speculation aside, your early checking stuff looks nice, especially since
> we are replacing our old and busted list system with Mailman's new hotness...

yeah. If you need all of Mailman's functionality for
determining which posters are/aren't permitted, then you
should probably throw out my code and use something which
constructs a fake message object and passes it through as
many of the Mailman handlers as are relevant -- the
alternative is to cut and paste all of the rest of the ACL
logic in Mailman into the test script, which is not
sensible long-term. But for the restricted case I'm
interested in the current solution is working well :-)

--
``Well, we can't stay all night here with a hyaena.''
``I don't know what your ideas of comfort are, but I shouldn't think
of staying here even without a hyaena.'' (Saki, from `Esme')