
Mailman: Proposed sender-based passwords
Note: this is based on Mailman 2.1.8 which, at the time of writing, is the
current version.
A discussion "approval password linked to sender rather than list?" on
mailman-users around 15 May 2006 agreed on the desirability of a variant
of the "Approved: password" mechanism, whose permission-granting password
would be associated with the email's sender rather than with the list.
The motivation is large sites with many "announcement" lists (in our case
over 2,000), where the entire membership of each such list is moderated,
and where several legitimate senders might regularly need to post single
emails to several lists. These lists might well exist in clusters.
But the option of allowing unmoderated access for those legitimate senders
opens up a major problem with spoofed email. So everyone needs to be
moderated.
But then the potentially useful moderation-bypass "Approved: listpw"
mechanism has the problems of requiring many people to share a particular
list's password, and of the passwords across a cluster of lists having to
be common. This "shared secret" problem grows even more alarmingly if the
list clusters overlap which would force reduction to a single password
across many lists, and widespread knowledge (hence leakage potential) of
that password.
Introducing an "Approval:"-like mechanism, whose password is associated
with the sender ("From:"), is intended address all this.
Virtual host considerations
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mailman is beginning to allow some virtual hosting (i.e. multiple domains
("...@dom1", "...@dom2"). Although this is currently limited (cannot have
the same listname at multiple domains) it is clearly on the roadmap for
the future. Accordingly this password proposal attempts to take full
account of that direction.
New "sender" role
~~~~~~~~~~~~~~~~~
Currently, according to "Mailman/SecurityManager.py":
# There are current 5 roles defined in Mailman, [...]
# user, list-creator, list-moderator, list-admin, site-admin.
That is, five contexts in which passwords are used and supported.
Clarification: "user" means the intersection of a particular email address
and a particular list: the (in)famous "monthly password reminder" entity.
Put another way: the same person (email address) on 'n' different lists
is actually 'n' unrelated "users".
A new "sender" role is proposed, available across all lists at all virtual
hosts. It is implemeted as a site-wide database of email addresses and
their passwords, with the same variety of options for encryption and
storage as in (or potentially in) the other databases. Across virtual
hosts it similarly remains the same, common, sender.
Clarification: Unlike a "user", this is a single stored-once entity,
representing a single email address across the entire installation.
In each list a new list-admin function maintains a set of email addresses,
herein called "authorised_senders", that can post through the list. On
the GUI, this would present a little like various "*_these_nonmembers".
An incoming email can specify "Authorised: sender-password" in the manner
of the existing "Approved: list-password" mechanism (headers, first real
blank-separated line, etc.).
[Note: I have chosen a separate word "Authorised:". Perhaps we can
conflate this new concept onto "Approved:" if there would be no loss of
functionality. If so, then "authorised_senders" should perhaps be called
"approved_senders".]
Its processing confirms the "From:" in the list's "authorised_senders",
then does an authorisation check against the site-wide "sender" (role)
database. (If we conflate "Authorised:" and "Approved:", the password
check would potentially need to be done on both the list and the "sender"
databases.)
If an incoming "Authorised:" email is destined for several lists, perhaps
at several virtual hosts, its "From:" is processed within each list as
described above against the site-wide "sender" database.
Maintenance of "sender"
~~~~~~~~~~~~~~~~~~~~~~~
The new "sender" database requires maintenance.
Insertion: How are email addresses and their passwords added? How is it
requested? By whom or by what is it implemented? What should be done to
detect and prevent malicious (spam-like, DOS-like) mass sign-up?
Deletion: How can an email address be removed from the database? When it
is removed, how is that reflected back into all the lists which had it in
their "authorised_senders" table? (Analogous to removing a file in a
filesystem but leaving behind dangling symbolic links.) Should those
lists be left alone (but now containing redundant entries) or should their
tables be amended? Suppose the deletion from "senders" was accidental or
transient: how can any removed entries in the several "authorised_senders"
tables be efficently restored?
Changes: How does someone maintain (change) their email address and
password?
If a person changes their email address how is that reflected back to the
lists? (See "Deletion".) Intuitively, the database key would have been
the email address. But perhaps the real key should rather be some opaque,
unique (UUID-like?) entity, with the email address simply being an
attribute.
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :

At 3:19 PM +0100 2006-05-19, David Lee wrote:
Yup.
and of the passwords across a cluster of lists having to
be common.
I'm not convinced that's necessary. Each list could have their
own approval password, and there is no technical reason why they would need to share that password with any other list.
That said, there may be operational reasons why you might end up
going down this road, such as people not being good at remembering large numbers of passwords.
Beyond that, I'm not sure that I can contribute much of anything
more to this discussion.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.

On Fri, 19 May 2006, Brad Knowles wrote:
One of our site's uses is people in the top-level management of the university sending out an email (a few per week) to a set (order ten) of announcement lists. The set of lists might vary from email to email (e.g. email-1 about exams to the all student lists; email-2 about marking to to the academic-staff list and to the secretarial list; email-3 about holiday cover to all the staff lists).
From: a.supremo@here.dom.ain To: list-1@here.dom.ain, list-2@here.dom.ain, ... list-10@here.dom.ain
My understanding is that to get this email straight through using the "Approved:" mechanism all those lists (i.e. their superset) would currently need to share a common password. (I haven't seen documented the ability to have multiple one-per-list, "Approved:" lines.)
If I've misunderstood this functionality (i.e. perceived limitation) please let me know... it's central to what I'm looking for!
And then there might be another cluster of announcement lists, say within a particular department, with a basically different set of people who would post, and so with a different password on their lists. But it might be highly desirable to permit occasional posting by a subset of the former (top-level management) group of people. They certainly won't want to have to know those (different) list-based passwords for the list clusters in and across every department!
Hence my suggestion of a person's (single) personal "sender" password into the overall system, entitling them to send to those Mailman lists whose "authorised_senders" includes them. This might be viewed as (very roughly) analogous to single sign-on.
On the big, university-wide lists, the "authorised_senders" group would typically be the university's top-level management, and people such as "postmaster". On the departmental lists, "authorised_senders" might be several (all?) staff in the department, perhaps occasional guests, and (again) some (all?) of the university's top-level management.
Does that help.
Beyond that, I'm not sure that I can contribute much of anything more to this discussion.
Simply sanity-checking my reasoning from your experience of mailman. (Whether you agree is another matter!) Until three weeks ago, I had never run a mailman installation, so I feel like a fish almost out of water.
Thanks. Best wishes.
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

David Lee wrote:
You are correct. The alternative is to send 10 individual posts, each to a single list with that list's approval.
We definitely want to move towards a single 'user identity/account' per person per site with a single authorization and multiple email addresses and subscriptions. Quoting from the todo list <http://www.list.org/todo.html>
# Have one account per user per site, with multiple email addresses and fallbacks. Allow them to subscribe whichever address they want to whichever list, with different options per subscription.
Given that infrastructure, it seems simple to implement the authorized poster concept.
In the mean time, I think you could accomplish much of what you want with a custom handler. It would need to have access to a user file which defined the user's capabilities and posting password, but it would be simple for it to then use some feature of the message to validate the poster, remove the secret information and set the approved flag in the message metadata (not the Approved: header, but the flag that the Approved header causes to be set.)
See Mailman/Handlers/Approve.py for an example of doing approval and see <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.067.htp> for more on custom handlers.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Fri, 2006-05-19 at 15:21 -0700, Mark Sapiro wrote:
Yes, this is definitely on the list!
Another possibility is to extend Approve.py to accept multiple Approved: headers. This would be fairly easy: you need to use Message.get_all() and loop through every header value you found. You'd probably also want to extend the body search to accept multiple Approved lines as the first in a text/plain part. Additionally, you'd probably want to put some mm_cfg.py defined maximum number of headers to accept to cut down on trolling for passwords.
-Barry

On Sat, 20 May 2006, Barry Warsaw wrote:
OK-ish for techie-like posters. And probably OK for some sites. But for this particular environment at this site, the typical senders are senior university managers, not techies. Even assuming (a big assumption) that (politically) asking them to type ten "Approved:" lines was OK, what about error handling (e.g. two typos in that list? a typo in one of the instances of the "Approved:" word itself causing pw leakage to other lists? when they want (legimately) to post to other lists normally under a department's control? ...)
Thanks for the reply.
To me (admittedly a complete newcomer to Mailman) the proper solution seems to be in recognising the large commonality of my "authorised sender" query with the "todo" item about personal accounts and going from there.
(Also if I, a Mailman newcomer, start charging around in the middle of the code for a local, supposedly "quick fix" usage, I might inadvertently make all sorts of blunders, creating corresponding non-quick support issues.)
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

On Fri, 19 May 2006, Mark Sapiro wrote:
Thanks for your reply. Much appreciated!
(Remember that I'm new to Mailman.)
I had seen that item in the "todo". That had felt as if it was oriented towards list members/recipients having a consistent subscription password across all the lists to which they belong (i.e. Mailman's output side) rather than towards posters/senders (Mailman's input side). I could see that in merging these two concepts, while there would be benefits, there might also be drawbacks. (Not sure what those drawbacks would be, but I didn't want to rush into merging two concepts (recipient control; sender control) which might have vital, if subtle, differences.)
Given that infrastructure, it seems simple to implement the authorized poster concept.
This suggests expanding the scope of the recipient-oriented "todo" item to cover potential senders.
This would seem to require almost the same data structure and support mechanisms that the "todo" item would require. (Or have I misunderstood?) It feels like a duplication of effort.
Wouldn't it be better for any "authorised sender" work that we (our site) might do to be a stepping stone towards achieving that "todo"? (The "todo" had recipients in mind whilst "authorised sender" has posters in mind, but see above for commonality.)
... which (if I understand correctly) would be an application-like thing making use of the services provided by the results of a "todo"-like thing.
Summary: The "todo" identifies a use for recipient-oriented accounts. Our "authorised sender" proposal identifies sender-oriented accounts. There is surely scope for signficant (even if not total) overlap in the underlying concepts, data, structures and code.
Should we (Mailman community, self included!) start addressing the "todo" account mechanism?
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

At 6:15 PM +0100 2006-05-19, David Lee wrote:
If you wanted to send to all of those lists with a single
message, that's probably true. However, I think that's also a sub-optimal way to send a message to mailing lists. If nothing else, I think it's really ugly for all recipients in all lists to get a complete list of all the other lists that were recipients of the original message.
You could resolve that with an umbrella list, but I'm not sure
where the list approval mechanism comes into play in that situation. Moreover, if the subset of lists the poster wanted to send to changed, then you'd have to create a new umbrella list, which would be a pain.
I'm not sure there is a good/easy solution to this part of the
problem, although it is probably mostly just cosmetic.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.

At 3:19 PM +0100 2006-05-19, David Lee wrote:
Yup.
and of the passwords across a cluster of lists having to
be common.
I'm not convinced that's necessary. Each list could have their
own approval password, and there is no technical reason why they would need to share that password with any other list.
That said, there may be operational reasons why you might end up
going down this road, such as people not being good at remembering large numbers of passwords.
Beyond that, I'm not sure that I can contribute much of anything
more to this discussion.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.

On Fri, 19 May 2006, Brad Knowles wrote:
One of our site's uses is people in the top-level management of the university sending out an email (a few per week) to a set (order ten) of announcement lists. The set of lists might vary from email to email (e.g. email-1 about exams to the all student lists; email-2 about marking to to the academic-staff list and to the secretarial list; email-3 about holiday cover to all the staff lists).
From: a.supremo@here.dom.ain To: list-1@here.dom.ain, list-2@here.dom.ain, ... list-10@here.dom.ain
My understanding is that to get this email straight through using the "Approved:" mechanism all those lists (i.e. their superset) would currently need to share a common password. (I haven't seen documented the ability to have multiple one-per-list, "Approved:" lines.)
If I've misunderstood this functionality (i.e. perceived limitation) please let me know... it's central to what I'm looking for!
And then there might be another cluster of announcement lists, say within a particular department, with a basically different set of people who would post, and so with a different password on their lists. But it might be highly desirable to permit occasional posting by a subset of the former (top-level management) group of people. They certainly won't want to have to know those (different) list-based passwords for the list clusters in and across every department!
Hence my suggestion of a person's (single) personal "sender" password into the overall system, entitling them to send to those Mailman lists whose "authorised_senders" includes them. This might be viewed as (very roughly) analogous to single sign-on.
On the big, university-wide lists, the "authorised_senders" group would typically be the university's top-level management, and people such as "postmaster". On the departmental lists, "authorised_senders" might be several (all?) staff in the department, perhaps occasional guests, and (again) some (all?) of the university's top-level management.
Does that help.
Beyond that, I'm not sure that I can contribute much of anything more to this discussion.
Simply sanity-checking my reasoning from your experience of mailman. (Whether you agree is another matter!) Until three weeks ago, I had never run a mailman installation, so I feel like a fish almost out of water.
Thanks. Best wishes.
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

David Lee wrote:
You are correct. The alternative is to send 10 individual posts, each to a single list with that list's approval.
We definitely want to move towards a single 'user identity/account' per person per site with a single authorization and multiple email addresses and subscriptions. Quoting from the todo list <http://www.list.org/todo.html>
# Have one account per user per site, with multiple email addresses and fallbacks. Allow them to subscribe whichever address they want to whichever list, with different options per subscription.
Given that infrastructure, it seems simple to implement the authorized poster concept.
In the mean time, I think you could accomplish much of what you want with a custom handler. It would need to have access to a user file which defined the user's capabilities and posting password, but it would be simple for it to then use some feature of the message to validate the poster, remove the secret information and set the approved flag in the message metadata (not the Approved: header, but the flag that the Approved header causes to be set.)
See Mailman/Handlers/Approve.py for an example of doing approval and see <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.067.htp> for more on custom handlers.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Fri, 2006-05-19 at 15:21 -0700, Mark Sapiro wrote:
Yes, this is definitely on the list!
Another possibility is to extend Approve.py to accept multiple Approved: headers. This would be fairly easy: you need to use Message.get_all() and loop through every header value you found. You'd probably also want to extend the body search to accept multiple Approved lines as the first in a text/plain part. Additionally, you'd probably want to put some mm_cfg.py defined maximum number of headers to accept to cut down on trolling for passwords.
-Barry

On Sat, 20 May 2006, Barry Warsaw wrote:
OK-ish for techie-like posters. And probably OK for some sites. But for this particular environment at this site, the typical senders are senior university managers, not techies. Even assuming (a big assumption) that (politically) asking them to type ten "Approved:" lines was OK, what about error handling (e.g. two typos in that list? a typo in one of the instances of the "Approved:" word itself causing pw leakage to other lists? when they want (legimately) to post to other lists normally under a department's control? ...)
Thanks for the reply.
To me (admittedly a complete newcomer to Mailman) the proper solution seems to be in recognising the large commonality of my "authorised sender" query with the "todo" item about personal accounts and going from there.
(Also if I, a Mailman newcomer, start charging around in the middle of the code for a local, supposedly "quick fix" usage, I might inadvertently make all sorts of blunders, creating corresponding non-quick support issues.)
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

On Fri, 19 May 2006, Mark Sapiro wrote:
Thanks for your reply. Much appreciated!
(Remember that I'm new to Mailman.)
I had seen that item in the "todo". That had felt as if it was oriented towards list members/recipients having a consistent subscription password across all the lists to which they belong (i.e. Mailman's output side) rather than towards posters/senders (Mailman's input side). I could see that in merging these two concepts, while there would be benefits, there might also be drawbacks. (Not sure what those drawbacks would be, but I didn't want to rush into merging two concepts (recipient control; sender control) which might have vital, if subtle, differences.)
Given that infrastructure, it seems simple to implement the authorized poster concept.
This suggests expanding the scope of the recipient-oriented "todo" item to cover potential senders.
This would seem to require almost the same data structure and support mechanisms that the "todo" item would require. (Or have I misunderstood?) It feels like a duplication of effort.
Wouldn't it be better for any "authorised sender" work that we (our site) might do to be a stepping stone towards achieving that "todo"? (The "todo" had recipients in mind whilst "authorised sender" has posters in mind, but see above for commonality.)
... which (if I understand correctly) would be an application-like thing making use of the services provided by the results of a "todo"-like thing.
Summary: The "todo" identifies a use for recipient-oriented accounts. Our "authorised sender" proposal identifies sender-oriented accounts. There is surely scope for signficant (even if not total) overlap in the underlying concepts, data, structures and code.
Should we (Mailman community, self included!) start addressing the "todo" account mechanism?
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

At 6:15 PM +0100 2006-05-19, David Lee wrote:
If you wanted to send to all of those lists with a single
message, that's probably true. However, I think that's also a sub-optimal way to send a message to mailing lists. If nothing else, I think it's really ugly for all recipients in all lists to get a complete list of all the other lists that were recipients of the original message.
You could resolve that with an umbrella list, but I'm not sure
where the list approval mechanism comes into play in that situation. Moreover, if the subset of lists the poster wanted to send to changed, then you'd have to create a new umbrella list, which would be a pain.
I'm not sure there is a good/easy solution to this part of the
problem, although it is probably mostly just cosmetic.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.
participants (4)
-
Barry Warsaw
-
Brad Knowles
-
David Lee
-
Mark Sapiro