>>>>> "NB" == Norbert Bollow <nb@thinkcoach.com> writes:
NB> Hmm... does this criticism also apply to Mj::MailOut.pm?
Not really; mailout is just there to deliver a message to a single
destination. The Deliver module is there to do "advanced delivery" using
delivery_rules to a certain zubscription class of a list. But I'll admit
that I've chosen the current method because it's easiest; if in the future
someone needs off-host delivery or direct qmail injection for simple
single-address replies then I can look into it.
NB> Anyway, I think I understand your point, and it makes sense.
Remember that I designed the whole Deliver interface so that Bouncefilter
could slot right in (given my limited knowledge of how Bouncefilter works; I
really should read the source fully some time).
NB> Actually, we won't even need any additional flags (and I'm glad about
NB> that, because Mj::Deliver::deliver() has enough arguments already.)
I would prefer to just add an argument instead of relying on magic, where
possible. Seven arguments plus the exclude list is not a large number,
especially if it makes the behavior obvious just from the arglist. Some
core functions take something like fifteen arguments. (But note that the
mode parameters to the core functions violate this; I'd try to get rid of
the modes in the core calls but there really isn't a better way to do it
once tokens get into the picture.)
NB> I think this is a good idea because it's straightforward to document:
NB> Set this variable to the owner-list e-mail address if the list-owner
NB> wants to handle bounces manually, or to bounncefilter's e-mail address
NB> if you want bouncefilter to handle bounces.
In the grand picture, the bounce filter/forwarder will always handle all
owner mail. That is how the address of the list owner(s) will be made
internally configurable: some piece of Majordomo will always intercept mail
to list-owner/owner-list. Whether or not it does bounce processing "the
hard way" (by trying to examine the bounce and find the bouncing address)
can be configurable, and if it sees a Bouncefilter bounce it can
automatically do the right thing.
This means that the list owner alias will just pipe to mj_bounce, which
will take it from there. I'll probably code up a skeleton mj_bounce in the
next few days to just forward the message to the owners.
NB> BTW, there is no chance of getting the bounce-handler that Mj ][
NB> deserves from me anytime in the near future.
That's fine; I'm going to pursue a regexp-based bounce recognition engine
given the regexp based packages I have available to me now. Perhaps once I
understand more about Bouncefilter I can just add the special capability
into the framework. But this is down the road for me, too; right now I
have more basic functionality to worry about.
Finish that thesis!
- J<
References:
|
|
