-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathNEWS
203 lines (154 loc) · 9.12 KB
/
NEWS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
-*- Text -*-
Here you'll find information on major changes. (Read the ChangeLog
for the boring stuff.) Items at the top are newer.
Digests are supported. Multiple digests can be defined per lists. Users
can elect to receive digests in test, MIME or index modes.
Users can elect to receive copies of their own messages or not, to receive
copies of messages from the server that were also carbon copied to them by
the original sender, to receive messages with or without a Reply-To: header
and with or without the subject_prefix.
Simplified patterns are supported; currently Majordomo will auto-escape
those pesky '@' signs that Perl now requires to be escaped (but only if the
regexp is illegal without such escaping). Substring patterns are also
supported, where no characters are magical. Perl patterns are enclosed in
'/' characters, while substring patterns are enclosed in '"'. Modifiers
('i' for case insensitivity, mainly) are also supported.
Alias generation is supported, as is virtusertable generation. Once set
up, in a single domain configuration new lists can be added without any
outside configuration; a single createlist command can do everything
required to set up a list.
Makefile.PL will force you to go through the Q&A process when new questions
are added.
The 'archive' command is supported; this command can return an index,
digest, or mbox-format collection of messages. Administrative features
allow messages to be edited or deleted. Messages from a date or range
of dates can be requested, as can lists of named messages and the last
several messages posted.
The user can be removed from the registration database and all lists at
once with the 'unregister' command.
There is a single, site-wide password that works as a global password for
all domains. It is set at install time and is changed by rerunning make
install.
The stock response files are no longer in each domain's filespace; they
exist outside all filespaces in a special SITE domain. This results in
disk space savings and a large speedup in the initial installation.
Each registered user has a password which can be changed by the user and
used to bypass the confirmation process. User passwords are supplied just
as owner passwords: using the approve command.
An internal reorganization places all data known about Majordomo commands
in one place, paving the way for easy extensions.
A new variable, 'advertise_subscribed' serves to globally select whether
users will be able to see a list if they are subscribed. If this is off,
the normal access restrictions on advertising apply. (Note that the
default is still to show the list, so this only servers to improve
performance slightly.)
The show command shows everything about an address, including data on all
of its subscriptions.
An internal rewrite has given a single database holding information about
all subscribers to all lists. A new 'register' command adds users to this
database without subscribing them to any lists. The register keeps track
of the lists a user is subscribed to, so several operations require only
one database access. This permits a single alias database and a simple
per-user password system.
The postinstall process is now very quiet unless verbosity is requested.
The shell interface has an interactive mode, with completion of commands,
lists and config variables, and command history.
Majordomo is immune to bad suggested filenames in MIME parts.
Resend can filter for long headers in MIME parts, partly to remove concerns
about messages which trigger buffer overflows in clients.
The createlist command can be used to generate an entire alias file for a
domain.
The separate mj_email, mj_resend and an abortive mj_request interfaces are
now unified into a single mj_email interface which accepts options to
control what is done with a message. This command accepts mail from all
addresses (majordomo, list, list-request, list-owner) and does what is
appropriate. Mail to list-owner is directed to the owners stored in a
config variable 'owners' while mail to list-request is acted on according
to the variable 'request-answer'. Mail to list-request can be sent to the
owner, replied to with a canned (and owner-selectable) message, or parsed
for commands.
The mj_email interface mentioned in the previous paragraph has been
superseded by a queueing system, using the mj_enqueue, mj_queueserv,
and mj_queuerun scripts. Queueing limits the load that is placed on
the system by a sudden influx of messages.
The database engine has been abstracted to allow different backends, with
automatic conversion as necessary. The text and DB_File backends have
been tested thoroughly. Experimental PostgreSQL and MySQL backends have
been implemented, but they should be used with caution.
Lockfiles are stored in a separate directory.
The configuration procedure can be told not to store passwords; they will
be prompted for at install time.
Taboo matchers allow negative severities.
Commands take modes/options with '=' or '-' as a separator, allowing the
more sensible 'command-action' form.
The message that is sent to the archives does not need to be identical to
the message distributed to the users. Header modifications and
fronters/footers are not present in the archived version. Attachments
stripped before sending can be present in the archived copy.
Archiving works; the archiver keeps index files containing data on each
message. Messages in the archive are assigned numbers and the index
provides exact byte offsets into the archive files. Archives can be split
by year, month, week, or day and further split by size.
Reply-To: headers work.
An mj_trigger command provides a way to signal Majordomo that periodic tasks
should be run. Two commands in the Majordomo user's crontab are all that
is required to have Majordomo take care of all necessary periodic
functions.
Default subscription flags can be set, along with a separate setting for
the flags associated with nonmembers.
A preliminary system for internationalization is in place although it is
not yet accessible to the user. A list administrator can set a default
language for the list. Some hard-coded English has not yet been removed
from the code.
VERP-like envelope extensions are supported. The list can be bounce-probed
in pieces; Majordomo2 will automatically probe different addresses each
time.
Many new bits of information about list messages are computed and made
available to the access_rules configuration setting. These include
number of bytes, lines and quoted lines, percentage of quoted lines,
size of header, and longest header.
Taboo matches can now be named; named matches accumulate severity
separately. Named matches can be referenced separately in the access
control language. Capitalized names additionally do not generate bounce
reasons.
Numeric comparisons for appropriate variables are now available in the
access control language. This allows for statements like '$admin_header >
20 && $lines <= 3'.
The address validator is a little smarter about illegal characters and long
host and user names. The configurable parameters are now settable through
global configuration settings.
Information on each "connection to the server" (called a session) is
stored and referenced in the logs and in each confirmation token. When
a token is rejected, information (including the session contents) is
sent to the victim, the list owner and majordomo-owner. The tokeninfo
and sessioninfo commands return data on tokens and sessions.
get, index, put, info, intro, faq, newinfo, newintro, and newfaq all work.
Majordomo includes a simple "virtual filesystem"; get, put and index work
with pathnames within this filesystem. When "absolute paths" are not
provided, everything defaults to a public directory which means that nobody
notices the change.
Denied posts are now acked if the proper flag is set. The returned
message for posting denial is much clearer and includes the denial
reasons. (Actually, it includes all of the things wrong with the
message, even if some of them wouldn't have caused a denial.)
Attachment rules and attachment filters are supported. The rules allow
a list owner to restrict messages with unwanted MIME parts. The filters
allow MIME parts to be removed or reformatted.
Fronters and footers are now implemented. The provision is made to
have several fronters and several footers and to randomly choose
between them. Also, additional variables controlling how often
fronters and footers are added are implemented. Care is taken so that
multipart messages are properly dealt with and that types other than
text/plain are not mangled.
Posting and approval are now functional; all of the old approval
methods are supported, in addition to several new MIME-aware methods
and the token based method and the post command.
Most of the access system works correctly, including many the default
actions. subscribe_policy and (no)?advertise work in a
backward-compatible manner.
Default replies from the access restriction system are implemented and
give useful information.
confirm and consult now work properly. Results go to the right place
(the victim always sees them, even if the victim wasn't the one
accepting the token).
Lots of stuff that is lost in time.