First a quick note: if you were using my one-line fix to turn off address
stripping of zubscription addresses, beware that it doesn't work with
confirmed zubscribes because that code has a bug which was mostly hidden by
the mandatory stripping. I have three more lines of fix to deal with that,
which will be in this patch.
I've been working on a big set of patches to alpha9 centered around
cleaning up mailer invocation (some of which I already sent out but
received no feedback on) and collecting various little changes I've passed
out over the past few weeks. The mailer stuff is especially nasty; it
looks as if three people tried different things and none of them finished
what they were working on (functions that do nothing but variables which
are never used, etc.). Here's a list of what I'm working on:
Move skip_headers out of resend; make it configurable. (resend,
majordomo.cf, config_parse.pl) Make global_delete_headers and
delete_headers, one a per-list config. These delete headers from the
original message before passing it on.
Add regexp arrays for restrictions for everything that allows
open/closed/list restrictions (who, lists, info) so people can limit these
to their domains. Sort of like noadvertise. (config_parse.pl, majordomo)
Add optional second argument to mkdigest to specify outgoing list name.
(majordomo)
- Done
Make big $mailer update to resend, allow special-casing $mailer in
majordomo.cf. This should make it easier on those (resend, majordomo?, majordomo.cf)
- Done, but needs testing
Avoid stripping in RetMailAddr. (majordomo.pl)
- Done
- Bug: do_auth bombs if address has spaces. FIXED
Turn off dash interception only on MIME multipart messages (majordomo).
- Done
Allow $restrict_post list to be whitespace or : separated, instead of just
\t, \n, or : separated.
- Done
Remove unused and undocumented `m' option to resend. (resend)
- Done
Documentation updates for new approval methods, per5 `@' escaping, new
mkdigest option, etc.
- Done
I'm looking for any idea while I'm in the central code, and also for any
comments on any of this; especially the first two items. The first makes a
good bit of sense, as $skip_headers is in the wrong place and it would be
nice to allow list owners to decide if they want to strip out X-Face:
headers and such. Can anyone see any security problems in allowing this?
There's nothing you can't do with this that you couldn't do by making your
list moderated and editing out headers from messages you approve.
For the second item, we keep being asked how to limit a feature to those
within a company or somesuch. We have noadvertise; I think more
configurability along those lines is called for. I'm not sure how to make
it visible, though. Perhaps in *_access, as another parameter, like
+allow, which performs the normal check and, if it fails, make another
check against the restriction regexps and allow the request if they match.
That way you could say closed+allow to allow only those from your company
to access the command, or list+allow to allow both subscribers and company
users.
I'm still not sure, though. It seems like you'd also want the opposite,
+restrict (which I could easily do). Please bombard me with ideas.
--
Jason L. Tibbitts III - tibbs@uh.edu - 713/743-8684 - 221SR1
System Manager: University of Houston High Performance Computing Center
1994 PC800 "Kuroneko" DoD# 1723
Follow-Ups:
|
|
