Hi Jason & List Members,
Thanks for the CC, I am a subscriber... just joined, so further CC's are
unnecessary. Anyway, thanks for the compliment, but I wouldn't call it good
spotting. If the code wasn't so well organized and commented I would never
have found it.
Now, if modifying sendmail.cf is beyond the scope of what Majordomo 2 is
intended to do (which makes perfect sense since there are so many MTA's and
different versions of those MTA's out there, then I would suggest strongly
that Majordomo make use of only 1 alias file and only 1 vut file. Messing
around with sendmail.cf is NOT complicated, but for a large site, adding an
entry for every alias and vut file for a large site is not what I would call
user friendly. Furthermore, I don't see why multiple files are necessary
when the entries are commented so well. It's quite easy to open up an alias
or vut file and see exactly what domain and what list the entries correspond
to. I would much rather make entries in sendmail.cf ONCE regardless of the
number of domains and lists that I host and then just let it run. Sendmail
can be configured to AutoRebuild Aliases (at least the version I use can
be... sendmail 8.9.2) but I am unaware of an AutoRebuild for virtuser
entries. If Majordomo could issue a command like
makemap hash majordomovirtuserfile.db < majordomovirtuserfile whenever it
modifies it's virtuserfile so that the virtuser entries are immediately
useable to sendmail then you would have the PERFECT MLM as far as I'm
concerned... it would be a lot easier for site administrators to set up and
maintain by minimizing what needs to be done with sendmail.cf and what needs
to be done manually.
I run a web hosting business (well, just starting one). This is what I'm
getting at. I want to offer each domain hosting customer the ability to
have unlimited majordomo lists at their domain. I also want to provide a
domain at which there will be a FREE public majordomo which anyone can
create a list on (this will be used for advertising in message fronters and
footers) Leaving it open like this means there will likely be LOTS of lists
created on a regular basis, and if I have to modify sendmail.cf each time a
new domain is added, and manually rebuild the virtuser database each time a
list is created then It has the potential to swallow up a great deal of my
time unnecessarily and I don't think this would be a situation that would be
unique to me. I suppose I could implement a cron job to periodically
rebuild the virtuser databases, but that again is not the best solution
since it lacks the ability to make newly created lists immediately useable
by the list owner/creator.
For the FREE public list, I'd like to be able to have a master fronter and
footer file so I can have the same ad display on all lists, and change the
ad for all the lists by modifying just one file. I understand that there is
to be a rotation feature... this also sounds GREAT!!!
Also, I would like to see a feature that would allow the Majordomo Owner
(the MAIN guy who runs the server) be able to set up a new domain by sending
commands via email if this is not too much of a security risk. I apologize
if that feature does exist, but if it does I've missed it in the
I would also like to see majordomo implement the following... first,
whenever a new domain is added, modify the majordomo user's cron file to
include the new entries, and second, I'd like to see a mechanism in place to
run a test to see if cronjobs are enabled and properly set up/functioning
for the majordomo user.
The createlist command works great, but I'm missing intro files being sent
to the list owner... has this feature not yet been implemented?
I also don't see a global policy setting for subscribe, it seems to be set
to open+confirm by default but I don't see the entry for that in the GLOBAL
Anyway... very excited about this new version. It looks like exactly what I
was looking for. I'd been racking my brain trying to figure out how to get
1.94.4 to emulate some of these features until I found the new version...
incidentally, I was able to cvs the latest build... thank you. I'm not much
of a programmer, but I would like to offer my assistance in the way of
suggestions, tracking down the occassional bug and what not. And if it
would be helpful, I'm willing to open up my server to the developers so they
can see majordomo 2 in action on FreeBSD 2.2.8 with Sendmail 8.9.2. I don't
want to give away any root passwords to anyone obviously but I'm certainly
willing to create some login accounts so developers at least have read
access and can see what's going on... and of course I'll run as many test
lists as you like so we can see this thing working on this platform.
>From: Jason L Tibbitts III <email@example.com>
>Cc: "Sean Proske" <firstname.lastname@example.org>
>Subject: Re: Newbie Introduction
>Date: Fri, Jan 8, 1999, 9:44 PM
>I'm sending you a CC because I'm not sure that you're a list member; if
>you'd rather not receive one, just let me know.
>>>>>> "SP" == Sean Proske <email@example.com> writes:
>SP> I'm wondering though if I've got the latest version, if not then could
>SP> someone please point me to an ftp site where I can update from?
>Check out http://www.hpc.uh.edu/majordomo/. There's a public CVS tree that
>you can update from. I will admit that I've been remiss in putting up
>snapshots for FTP.
>SP> The following section of code causes mj-vut entries to be written to
>SP> the mj-alias file instead:
>Good spotting. Yes, that's still in my code, and the change looks like the
>right thing to do. I've fixed it in my tree.
>SP> I also have a suggestion or two.
>I'm always glad to hear them.
>SP> When creating new vutfiles or modifying them, it would be REALLY nice
>SP> if it could makemap hash the corresponding database file.
>Yes, I do have a TODO list item for calling out to newaliases and makemap
>to do the rebuilds at the appropriate time.
>SP> Adding a Kvirtuser line to the sendmail.cf file would also be a bit of
>SP> a blessing.
>Playing around with sendmail.cf is beyond the scope of what Majordomo
>should be doing, I think. But it should be something you do once and don't
>bother with again.
>As you might guess, I don't use the virtual stuff; the code that is there
>is based entirely on some suggestions about how some folks think it might
>work and a quick read through Sendmail's op guide. I would really
>appreciate feedback here, since I really don't know if the code works at
>SP> Also, I would find it much more convenient if instead of writing a
>SP> separate alias file for each domain, it would just write to a single
>SP> alias file for majordomo
>The problem is that the individual domains don't know about each other;
>there's no way for them to rebuild each other's alias files when one adds a
>SP> The reason being is that after a handful of domains have been added,
>SP> the sendmail.cf file's alias line would easily become rather
>SP> unmanageable in length... particularly to remote administrators who use
>SP> telnet clients.
>XYX:sina:~> grep AliasFile /etc/sendmail.cf
>/home/tibbs/mj/lists/ALIASES/mj-alias-hpc.uh.edu: 43 aliases, longest 78
>bytes, 2945 bytes total
>/etc/mail/aliases: 30 aliases, longest 43 bytes, 734 bytes total
>/usr/local/lists/aliases: 65 aliases, longest 106 bytes, 2863 bytes total
>No reason you have to put them all on one line. Now, I just found this
>out, so I do need to update README.SENDMAIL.
>SP> Looking forward to seeing the final release, but in the meantime... if
>SP> there is a more current alpha or beta version of Majordomo 2 than the
>SP> one I've just installed, PLEASE point me to a site I can obtain an
>SP> update from.
>If you can, try CVS. What's in there has progressed quite a bit from
>what's in the snapshot you have.
> - J<