Great Circle Associates Majordomo-Workers
(March 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: [Fwd: Re: Syntax for a 'set' command?]
From: Jason L Tibbitts III <tibbs @ hpc . uh . edu>
Date: 22 Mar 1997 22:09:48 -0600
To: Chael Hall <nowhere @ chaos . taylored . com>
Cc: majordomo-workers @ greatcircle . com
In-reply-to: Chael Hall's message of Sat, 22 Mar 1997 22:42:13 -0500 (EST)
References: <Pine.BSF.3.95.970322223024.13552A-100000@chaos.taylored.com>

>>>>> "CH" == Chael Hall <nowhere@chaos.taylored.com> writes:

CH> Does the new Mj provide its own delivery engine?

Sort of.  Majordomo, like TLB, doesn't really "deliver" anything.  It just
passes the recipient list to a machine running an MTA which is capable of
doing delivery.  My implementation does this via SMTP, which is standard,
supported, and doesn't involve futzing with possible insecurities calling
sendmail and doesn't force anyone to worry about command line arguments or
where sendmail is sitting or if sendmail is really qmail or whatever.  It
also allows us to incorporate (some of) the functionality of TLB, like
using multiple hosts for outgoing delivery in parallel.

CH> I like the way qmail handles message delivery already...  It works well
CH> with a flat file of recipients.

It does?  I thought it didn't handle things like comments in the address
very well at all.

CH> If there is an implementation that involves writing a file to disk
CH> containing the recipient list, that would work for me.

Tell me how sending multiple messages out to possibly different lists of
addresses would work.  (Think of noselfcopy, duplicate suppression and
subscriber classes.)  You can't use an outgoing alias; you could use
several, but I don't want to think about that.  If your MTA will take the
filename on the command line then you have a possibility, but I think the
way I have it would work for now.

In any case, if you just can't stomach delivery as I've coded it, the
solution is simple.  Just change out the Deliver.pm module.  Or write a
user routine that redefines the one entry point into the delivery engine to
call whatever you want.

CH> The other feature was really a cluster of features made possible by
CH> using a database format (albeit a text file database.)

I have a simple database (SimpleDB.pm) which SubscriberList, AddressList
and AliasList inherit from.  It's just tab separated fields semi-designed
to simulate a real database.  Really easy to convert to something more
elaborate, too, like db_File or mySQL.  This is the real reason I do my own
"delivery"; there's no "address file" and the overhead of writing a new one
for every message (think big lists) is too much.

CH> It was auto unsubscription for bouncing addresses, postponing mail (I
CH> saw that on your list), keeping subscriber names (I use strip because
CH> my mailer doesn't like "superfluous" stuff in the list files.)

This is all supported, in theory.  I would really appreciate it if someone
would design a real batch processing engine.  qmail's owner hack is great,
and I know how to simulate it with Sendmail, but I'm not ready to get into
that now.  I already allocated a field in which to store some "bounce data"
but I have no idea what would go in there.

>> The defaults stick around.  (Default list works just like -l does now;
>> in fact calling mj_email with -l just does an implicit "default list
>> $opts{l}".)  You can unset them with

CH> Great!  Is that available in 1.94.1?

Nope.  1.9x doesn't really have much of a parser, and the commands (like
approve and auth) call each other when the parser should take care of them.
The whole thing is implemented much more cleanly (IMHO) in my code.

CH> The dashes are better, but people won't always put them in.  The hack
CH> to redirect "list digest" to "list-digest" is trivial, so I would
CH> implement it as I described the other feature above.

You're right; the problem is that (as Dave can tell you) I have this thing
about parser ambiguity.  (If the list name is "digest", what do you do?)
Still, I think I can handle that one.  Either way, then.

CH> Sorry!  I know it's a bit more work, but the idea is to make it easier
CH> for people to get along with the list software.  Since this is a goal,
CH> a certain amount of forgiveness is required.

Work, work.  I'm past 10000 lines now and not nearly half done.  You're
right, of course; the goal is to make things easier.

 - J<


Follow-Ups:
References:
Indexed By Date Previous: Re: [Fwd: Re: Syntax for a 'set' command?]
From: Chael Hall <nowhere@chaos.taylored.com>
Next: Re: [Fwd: Re: Syntax for a 'set' command?]
From: Chael Hall <nowhere@chaos.taylored.com>
Indexed By Thread Previous: Re: [Fwd: Re: Syntax for a 'set' command?]
From: Chael Hall <nowhere@chaos.taylored.com>
Next: Re: [Fwd: Re: Syntax for a 'set' command?]
From: Chael Hall <nowhere@chaos.taylored.com>

Google
 
Search Internet Search www.greatcircle.com