> NB> [...] I'm going to call validate from bf-batcher (a replacement for TLB
> NB> which will allow Bouncefilter to be used outside of its natural
> NB> environment
> That's one of the reasons I removed the validator's need for globals.
> You'll probably have to get rid of the logging calls, though.
> When you say you're "replacing" TLB, are you duplicating all of the
Only if that doesn't create significant extra work. My intention is to
provide some kind of way to use Bouncefilter with Majordomo 1 that can
easily be ported to other MLMs. If your hint about delivery_rules turns
out to give me an easy way of creating something which duplicates all of
TLB's functionality, that is of course even better than what I originally
> Unless you're rolling it all yourself, I think the
> Mj::Deliver code is better than what's in TLB.
Yes! And that's precisely the reason why I'm working on something that
can replace TLB rather than a patch for it.
bf-batcher is a pretty short script actually, it essentially puts the
message (which comes from STDIN) into a temporary file, finds out where
the file with the subscriber addresses is, reads it, validates addresses
and then relies on Bf::Sender->compatibility_deliver() to mail the message
out. (bf-batcher also removes addresses of which validate() fails to make
sense even with lax settings and alerts the owner-list address about them.)
Bf::Sender is a module which will eventually be part of Majordomo. It
contains functions which make decisions about what to put into the
envelope sender and which then call Mj::Deliver->deliver(), or
Mj::Deliver::Envelope->new() and Mj::Deliver::Envelope->send(), or
Mj::Deliver::QQEnvelope->new() and Mj::Deliver::QQEnvelope->send() for
the actual work.
When my code is mature enough I will send you a patch that will cause
Mj::Deliver->deliver() to call Bf::Sender->choose_sender() on machines
with MTAs that support using Bouncefilter's fancy envelope sender
> And it might be nice to
> make use of the delivery_rules syntax so we have some uniformity.
> (delivery_rules allows all of the expressiveness of the TLB config file
> stuff without any Perl. And I'm proud of my nested keyed list parser.)
Great idea! Will do.
> This reminds me: the current lack of explicit copyright on the code means
> that you can't legally do anything with it. We're going to have to pick a
> license, which is something I've been dreading. I like an Apache/BSD style
> that says you can do anything you want except remove the copyright notice
> or advertise a derivative work as Majordomo.
> Unfortunately I hate legal
> stuff. Anyone want to form the "Majordomo Development Group" (or
> consortium or whatever)?
Sounds like a good idea to me. Count me in :)