> 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
> functionality?
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
wanted.
> 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
addresses.
> 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.
I agree.
> 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 :)
-- NB.
Follow-Ups:
References:
|
|
