#
# Brent, el al:
#
# I've added perl code that does the following:
#
# - Traps non-local addresses, logs, then exits.
#
# - Modified the command interpreter loop to ignore lines
# that are automatically inserted at the top of the body
# of the message by QuickMail and cc:Mail. Note: I need
# to add a few more rules here.
Great!
# - Modify the command interpreter such that if the owner of the
# list sends a subscribe command the subscription is automatically
# done and an 'approve' message isn't sent back (since that's
# really an extra interation). NOTE: This feature may already
# be in the code, I haven't looked. I just know I need it.
#
# Brent - perhaps you can save me some time -- is this feature
# already in there?
No. Majordomo has no idea who the owner of a list is; it just sends
mail to "$list-approval", which is supposed to be an alias to whoever
the owner or owners are. Keep in mind that there might be multiple
owners of a given list.
Why doesn't the owner of the list just send in the approve request in
the first place? Majordomo doesn't keep track of pending approves, or
anything like that; you don't have to wait for it to send you an
approval request before you can approve something.
# Anyway, that's all for now, more later...
#
# Tim
#
# P.S. Perl code mods are below. Disclaimer: the code could probably
# be cleaner and might not be placed in the optimal place in the
# algorithm. Comments, suggestions, etc. are welcome.
Can you send me back "diff -c" output? That makes it easier to do the
patches later. Also, do these mods follow my general guidelines for
Majordomo enhancements? Here they are:
0) Start with the latest Majordomo release. If it's been a while since
the latest release, contact me; I might send you a copy of the current
working but unreleased code for you to modify, to ease integration.
1) Anything you add (other than bug fixes to existing code) should be
configurable.
2) If it is something site-wide (for instance, what mailer to use), it
should be controlled through variables in the .cf file, and should
default to the old, unmodified behavior if these variables aren't
specified.
3) If it is something list-specific (for instance, whether a given
list is open or closed), it should be controlled with a
"<list>.<flag>" file (such as the existing "<list>.closed" or
"<list>.passwd" files), again defaulting to the old, unmodified
behavior of the flag file doesn't exist.
Thanks!
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
|
|
