![](https://secure.gravatar.com/avatar/fcc130bb83ad0cf89fd7bf173cd5523a.jpg?s=120&d=mm&r=g)
(Background: new to Mailman. Trialling 2.1.8 prior to wider roll-out.)
Minor mismatch in web interface terminology:
Whilst guiding a potential list-owner through the approval/moderation procedure, I spotted an inconsistency. A typical "http://.../admindb/..." page ("Administrative requests for mailing list: ...") has a four way radio button, with one being labelled "Accept". But its "More detailed instructions" link to "Detailed instructions for the administrative database" then has this button described under the label "Approve".
This mixture of terminology seems to occur in other places also. You might want to consider rationalising these to the same thing for the sake of moderators who might be (say) secretarial staff.
Hope that helps.
--
: 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. :
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 6/6/06 9:23 AM, "David Lee" <t.d.lee@durham.ac.uk> wrote:
This mixture of terminology seems to occur in other places also. You might want to consider rationalising these to the same thing for the sake of moderators who might be (say) secretarial staff.
Secretarial staff should have no problem with the example given. The CEO, on the other hand...
And yes, terminology should be consistent.
--John
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
David Lee wrote:
Whilst guiding a potential list-owner through the approval/moderation procedure, I spotted an inconsistency. A typical "http://.../admindb/..." page ("Administrative requests for mailing list: ...") has a four way radio button, with one being labelled "Accept". But its "More detailed instructions" link to "Detailed instructions for the administrative database" then has this button described under the label "Approve".
This mixture of terminology seems to occur in other places also. You might want to consider rationalising these to the same thing for the sake of moderators who might be (say) secretarial staff.
Thanks for the report. I will update the template as follows unless you have a better suggestion: Index: admindbdetails.html =================================================================== --- admindbdetails.html (revision 7905) +++ admindbdetails.html (working copy) @@ -14,7 +14,7 @@ postings, you can still forward or preserve the message (see below). -<li><b>Approve</b> -- Approve the message, sending it on to the list. +<li><b>Accept/Approve</b> -- Accept the message, sending it on to the list. For membership requests, approve the change in membership status. <li><b>Reject</b> -- Reject the message, sending a rejection notice to Since it is a template, you can fix your own and store the fixed version in templates/site/en/admindbdetails.html where it will survive updates (the base is templates/en/admindbdetails.html). See <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.048.htp>. -- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 6 Jun 2006 17:23:08 +0100 (BST) David Lee <t.d.lee@durham.ac.uk> wrote:
Whilst guiding a potential list-owner through the approval/moderation procedure, I spotted an inconsistency. A typical "http://.../admindb/..." page ("Administrative requests for mailing list: ...") has a four way radio button, with one being labelled "Accept". But its "More detailed instructions" link to "Detailed instructions for the administrative database" then has this button described under the label "Approve".
This mixture of terminology seems to occur in other places also. You might want to consider rationalising these to the same thing for the sake of moderators who might be (say) secretarial staff.
I agree, but which is the best term to use? Reading the dictionary entries for "approve" and "accept", I think I like the former:
ap_prove
- To consider right or good; think or speak favorably of.
- To consent to officially or formally; confirm or sanction: The Senate approved the treaty.
- Obsolete. To prove or attest.
ac_cept
- To receive (something offered), especially with gladness or approval: accepted a glass of water; accepted their contract.
- To admit to a group, organization, or place: accepted me as a new member of the club.
- To regard as proper, usual, or right: Such customs are widely accepted.
- To regard as true; believe in: Scientists have accepted the new theory.
- To understand as having a specific meaning.
- To endure resignedly or patiently: accept one's fate.
- To answer affirmatively: accept an invitation.
- To agree to take (a duty or responsibility).
- To be able to hold (something applied or inserted): This wood will not accept oil paints.
- To receive officially: accept the committee's report.
- To consent to pay, as by a signed agreement.
- Medicine. To receive (a transplanted organ or tissue) without immunological rejection.
Seems to me that definition #2 of "approve" is the closest to what a list administrator does.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIZM3nEjvBPtnXfVAQKjawP/TD9T+jWShYHuz8jhEQ2jMRNBS8i5Kl6j PXHICPW4a60QkuUPQMIhBHo9fNdDeU5zHSWA0+YBFT9g0q3PQ7//S2jDFsfEDf7M Nx0oeOWiMIWelUTA8zZVInmoheFfv6RMPXOZ7GE0+hnMZ2j1katxXzyLTXYwkS7r 35lYgye3Iqo= =cKGe -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Barry Warsaw wrote:
I agree, but which is the best term to use? Reading the dictionary entries for "approve" and "accept", I think I like the former:
Actually, both terms are used on the radio buttons on the admindb page. "Accept" is used for held posts, and "Approve" is used for (un)subscription requests.
We could of course change the name of the held message radio button to "Approve", but then we'd have an inconsistency with "Add poster@example.com to one of these sender filters:", and if we changed that, would we also want to change the name of accept_these_nonmembers?
It seemed simpler to me to just make the template change I indicated in my prior reply.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 6 June 2006 22:02:44 -0700 Mark Sapiro <msapiro@value.net> wrote:
Barry Warsaw wrote:
I agree, but which is the best term to use? Reading the dictionary entries for "approve" and "accept", I think I like the former:
Actually, both terms are used on the radio buttons on the admindb page. "Accept" is used for held posts, and "Approve" is used for (un)subscription requests.
We could of course change the name of the held message radio button to "Approve", but then we'd have an inconsistency with "Add poster@example.com to one of these sender filters:", and if we changed that, would we also want to change the name of accept_these_nonmembers?
It seemed simpler to me to just make the template change I indicated in my prior reply.
While we're here, can we change all instances of "reject" to "bounce". Mailman deals with queued messages, so it isn't capable of rejecting a message in the SMTP sense. All it can do is generate bounces - which are probably collateral spam.
Even better would be to integrate Mailman into MTA's better, so that the MTA can use Mailman data to reject spam.
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 07 Jun 2006 10:41:26 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
Even better would be to integrate Mailman into MTA's better, so that the MTA can use Mailman data to reject spam.
I think that will be problematic, given the wide variety of MTA extension frameworks. A better approach would be to structure the Mailman code in such a way that large parts of it can be used as a library, which could serve as the basis for sites writing their own MTA extension, or any other specialized Mailman-based application.
This is actually one of the main reasons why I've been moving the bulk of the bin and cron scripts to inside the top-level Mailman package for 2.2. Those scripts need to be refactored a bit better, but they do provide some useful higher-level operations that other Python programs can now get access to (e.g. by putting /usr/local/mailman on your sys.path and doing good ol' imports).
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIbT93EjvBPtnXfVAQJVOAP/eS5fiGp/mWdoTmlp8p98t8fcMnpgbJ1m ljwezQR+3G4FTPI6lymYqAN0xAqYKl4Nwfg6/n3XfUsteD5KaHKuXuTC/FYdMy8B XEDjXpNaq0bF8uHQWyJM7LAEr8nuKOMMgAJyLKE/mk1KHGoyiXm6JXaJXu0VB8ib rAGvZ5QUl+4= =1Z8K -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 7 June 2006 09:26:11 -0400 Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 07 Jun 2006 10:41:26 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
Even better would be to integrate Mailman into MTA's better, so that the MTA can use Mailman data to reject spam.
I think that will be problematic, given the wide variety of MTA extension frameworks.
Yes, of course.
A better approach would be to structure the Mailman code in such a way that large parts of it can be used as a library, which could serve as the basis for sites writing their own MTA extension, or any other specialized Mailman-based application.
Perhaps. Even better would be to hold rosters in open databases. Exim, for example, can read sql, ldap, flat files and so on. I don't think it's Mailman's job to examine the content of messages - that's the job of a spam or virus filter.
This is actually one of the main reasons why I've been moving the bulk of the bin and cron scripts to inside the top-level Mailman package for 2.2. Those scripts need to be refactored a bit better, but they do provide some useful higher-level operations that other Python programs can now get access to (e.g. by putting /usr/local/mailman on your sys.path and doing good ol' imports).
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIbT93EjvBPtnXfVAQJVOAP/eS5fiGp/mWdoTmlp8p98t8fcMnpgbJ1m ljwezQR+3G4FTPI6lymYqAN0xAqYKl4Nwfg6/n3XfUsteD5KaHKuXuTC/FYdMy8B XEDjXpNaq0bF8uHQWyJM7LAEr8nuKOMMgAJyLKE/mk1KHGoyiXm6JXaJXu0VB8ib rAGvZ5QUl+4= =1Z8K -----END PGP SIGNATURE-----
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 3:51 PM +0100 2006-06-07, Ian Eiloart wrote:
Perhaps. Even better would be to hold rosters in open databases. Exim, for example, can read sql, ldap, flat files and so on.
That's just rosters. That's a small part of the overall set of
things that Mailman is going to be looking at when it comes to deciding whether or not to accept or reject a given message.
Moreover, we've been trying to go to an integrated database model
for all data regarding users, but what you're proposing here would be a push towards simplified, almost flat, databases with minimal specific information about users, so that the MTA could parse that information and understand who was subscribed to what list.
Unless you've got some ideas of how to teach all MTAs how to
reach deeply into our database and pull out subscription information for a given message, I don't see how these two goals are anything but diametrically opposed.
We can't just be thinking of a single MTA here. Just because it
would be convenient to you to make all this magic happen in a way that would be perfectly fine for Exim, doesn't mean that we can ignore sendmail, postfix, and other programs.
If you want to write up some Exim-specific ways that would result
in a tighter integration between the MTA and Mailman, I think that would be fine so long as they don't cause architectural changes within Mailman that would result in a significantly worse integration with other MTAs.
I don't think it's
Mailman's job to examine the content of messages - that's the job of a spam or virus filter.
But once the spam or virus filter has done their work, we need to
look at that as part of the output in making our decisions.
I don't think there's any way in the world that you're going to
escape this.
-- 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/>.
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 7 Jun 2006 12:36:23 -0500 Brad Knowles <brad@stop.mail-abuse.org> wrote:
We can't just be thinking of a single MTA here. Just because it would be convenient to you to make all this magic happen in a way that would be perfectly fine for Exim, doesn't mean that we can ignore sendmail, postfix, and other programs.
If you want to write up some Exim-specific ways that would result in a tighter integration between the MTA and Mailman, I think that would be fine so long as they don't cause architectural changes within Mailman that would result in a significantly worse integration with other MTAs.
Totally agree. OTOH, don't most MTAs provide /some/ way to call external programs on messages at various points in their workflow? If so, then by providing richer and more unified Python APIs inside Mailman, we can at least allow for developers to write extension modules for their MTAs that more tightly couple Mailman and the MTA, without having to perform major surgery on Mailman or duplicate lots of code.
That's really the direction I'm heading in -- make Mailman more like a (Python) library that can be used to write custom "applications". Those applications wouldn't need to reach into our dbs directly because they ought to be able to get most answers to a question fairly directly.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIcccHEjvBPtnXfVAQJO1QP/aHkb6YJa8+Gw/CI5dzDu8vjbTc4OqFbv 8yqaywKPKSz5ZysMQWdKa4w8Kqypp3vkF6K9gxjQbGj2eE6yxMOJnDBUWow5KSGm heVUdUe3q3cM5QXrFr3uOL++JN7+FfA/xw4agJH/zL/+/65AKgzrlYGo8Ky/kU4B wIA9c92288g= =phJV -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:35 PM -0400 2006-06-07, Barry Warsaw wrote:
Totally agree. OTOH, don't most MTAs provide /some/ way to call external programs on messages at various points in their workflow?
Sendmail has milter, and that has now been brought into postfix
(as of 2.3), but I can't speak for any other MTAs. What would need to happen would be a custom program would have to be written for each MTA to interact with it in the way that MTA works, but which has a deep understanding of Mailman and the configuration for each list and recipient, and could effectively do a "dry run" for each message.
Of course, this would have to happen after the
anti-spam/anti-virus milters, and then some sites are going to use accept & scan techniques as opposed to milter, so there may need to be multiple different "MTA adapters", even for a particular MTA.
-- 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/>.
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 7 June 2006 23:32:01 -0500 Brad Knowles <brad@stop.mail-abuse.org> wrote:
At 2:35 PM -0400 2006-06-07, Barry Warsaw wrote:
Totally agree. OTOH, don't most MTAs provide /some/ way to call external programs on messages at various points in their workflow?
Sendmail has milter, and that has now been brought into postfix (as of 2.3), but I can't speak for any other MTAs. What would need to happen would be a custom program would have to be written for each MTA to interact with it in the way that MTA works, but which has a deep understanding of Mailman and the configuration for each list and recipient, and could effectively do a "dry run" for each message.
No, that's not true. What's required is that Mailman provide a simple API to allow MTA developers to ask Mailman whether a particular sender is permitted to post to the list. Holding rosters (a v3 proposal) in open databases would solve this problem - at least for Exim.
Although Mailman is capable of filtering on other factors, I don't think the number of cases is significant. However, it might be possible to extend the API to provide information on other list policies.
Of course, this would have to happen after the anti-spam/anti-virus milters, and then some sites are going to use accept & scan techniques as opposed to milter, so there may need to be multiple different "MTA adapters", even for a particular MTA.
If an MTA is doing accept and scan, then none of this is relevant. If the MTA doesn't query Mailman BEFORE accepting the message, then there's never any point in doing it at all.
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 12:20 PM +0100 2006-06-08, Ian Eiloart wrote:
No, that's not true. What's required is that Mailman provide a simple API to allow MTA developers to ask Mailman whether a particular sender is permitted to post to the list. Holding rosters (a v3 proposal) in open databases would solve this problem - at least for Exim.
That's fine, for Exim.
Although Mailman is capable of filtering on other factors, I don't think the number of cases is significant. However, it might be possible to extend the API to provide information on other list policies.
I disagree that it's not significant. If you want to extend the
"simple API" argument to other aspects of the filtering Mailman is capable of doing, that's fine.
But you still have to have something to use that API to tell the
MTA what it needs to know and when, and I don't think we can necessarily depend on the MTA authors to create that. Maybe the Exim authors could and would do so quickly, but that's not the only MTA we have to concern ourselves with.
-- 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/>.
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 8 June 2006 08:52:26 -0500 Brad Knowles <brad@stop.mail-abuse.org> wrote:
At 12:20 PM +0100 2006-06-08, Ian Eiloart wrote:
No, that's not true. What's required is that Mailman provide a simple API to allow MTA developers to ask Mailman whether a particular sender is permitted to post to the list. Holding rosters (a v3 proposal) in open databases would solve this problem - at least for Exim.
That's fine, for Exim.
Although Mailman is capable of filtering on other factors, I don't think the number of cases is significant. However, it might be possible to extend the API to provide information on other list policies.
I disagree that it's not significant. If you want to extend the "simple API" argument to other aspects of the filtering Mailman is capable of doing, that's fine.
But you still have to have something to use that API to tell the MTA what it needs to know and when, and I don't think we can necessarily depend on the MTA authors to create that. Maybe the Exim authors could and would do so quickly, but that's not the only MTA we have to concern ourselves with.
Well, that doesn't matter. Obviously no solution is going to work for *all* MTAs. Some couldn't work with *any* solution.
The thing is that if you decide that Mailman isn't going to share its data with anyone, then nobody can set up a Mailman system which doesn't generate collateral spam. I'm not suggesting that Mailman should relinquish its internal functionality, just that it should expose that functionality.
In fact, for exim, the MTA authors may have to do nothing, it might just be a matter of fixing the configuration. In fact, its conceivable that I could do that already, but I'd much rather know that Mailman developers had some kind of commitment to solving the collateral spam problem. And I'd like there to be a supported method for doing that (an API). At the moment, I ask my list administrators to NEVER automatically bounce (sorry, "reject") messages - and I don't think that's satisfactory.
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 08 Jun 2006 15:35:55 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
The thing is that if you decide that Mailman isn't going to share its data with anyone, then nobody can set up a Mailman system which doesn't generate collateral spam. I'm not suggesting that Mailman should relinquish its internal functionality, just that it should expose that functionality.
All of Mailman's functionality already /is/ exposed, although it may not be in a format you are familiar and/or comfortable with. I think a lot of people don't get this, so it's important to emphasize.
Mailman is more than just open source. Because it's written in Python, even a deployed and operational system has complete access to Mailman's implementation, not just its data. Take a look at the command line scripts some time. There's really nothing special about them because they use exactly the same exposed functionality as any MTA extension would use. The only thing special about them is that one of us wrote it and it comes with Mailman.
It's not like your typical MTA written in C where if they don't expose the right hooks, you're mostly SOL unless you can implement the hooks yourself, recompile and redeploy the new binary.
Okay, you have to be a Python programmer and you probably have to understand enough of Mailman to know what the consequences of your code is, but that really isn't a huge hurdle (certainly the former isn't for any experienced programmer and for the latter, that's why we're here! :).
In fact, for exim, the MTA authors may have to do nothing, it might just be a matter of fixing the configuration. In fact, its conceivable that I could do that already, but I'd much rather know that Mailman developers had some kind of commitment to solving the collateral spam problem. And I'd like there to be a supported method for doing that (an API). At the moment, I ask my list administrators to NEVER automatically bounce (sorry, "reject") messages - and I don't think that's satisfactory.
I certainly agree that the entire email stack has to be defensive about collateral spam. I do believe that scripts could be written that could help an MTA make /some/ decisions about the disposition of an email message lower down in that stack. I'm not even opposed to distributing some with Mailman that have a proven track record, nor am I opposed to refactoring some code and "blessing" some APIs that make this job easier with some guarantees of stability across releases. But I'm not going to write them. :) There really is nothing stopping anyone else from starting to do that now, if you think about the problem in the right way.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIhEPXEjvBPtnXfVAQJC/wP+KCPhMYf4nDYRJx9/gH4f5T4dy5TjFb0q AxvGWNNq7UZOisMQwnyF9VmEFDFBZDzAfCVttgDIRF27ZqTIDeMOdb8vayCmWk9T n5Yj+oo6iPNsgsKGce07rXSHWFEVTqb1xx55Tcv8O0qshoBpLGmITQG+ueBQ/h/0 J2icggSEFB4= =hiCr -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 8 June 2006 11:37:33 -0400 Barry Warsaw <barry@python.org> wrote:
In fact, for exim, the MTA authors may have to do nothing, it might just be a matter of fixing the configuration. In fact, its conceivable that I could do that already, but I'd much rather know that Mailman developers had some kind of commitment to solving the collateral spam problem. And I'd like there to be a supported method for doing that (an API). At the moment, I ask my list administrators to NEVER automatically bounce (sorry, "reject") messages - and I don't think that's satisfactory.
I certainly agree that the entire email stack has to be defensive about collateral spam. I do believe that scripts could be written that could help an MTA make /some/ decisions about the disposition of an email message lower down in that stack. I'm not even opposed to distributing some with Mailman that have a proven track record, nor am I opposed to refactoring some code and "blessing" some APIs that make this job easier with some guarantees of stability across releases. But I'm not going to write them. :) There really is nothing stopping anyone else from starting to do that now, if you think about the problem in the right way.
That's fair enough. I do have an idea about how to use a python script with Exim. I don't know enough to make it efficient, though. Maybe there's a problem with my python installation, or the way that I invoke it, but it seems that even a simple query takes four or five seconds to run:
rinka-12 # date ; /local/mailman/bin/list_members ian-test4 ; date Thu Jun 8 16:47:09 BST 2006 foo@example.ac.uk bar@example.ac.uk baz@example.ac.uk Thu Jun 8 16:47:13 BST 2006
But, it takes about 0.7 seconds to print "hello world", and truss shows a lot of files being opened just to get a list of members.
Now, my Exim installation makes up to about a dozen LDAP queries to deliver an email. The queries are cached, and my average time to deliver an email is a second or two - and that's including virus a spam scanning.
OK, maybe I should just get on and implement this. If Exim caches the results, then it's not going to be too bad.
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 08 Jun 2006 17:06:43 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
That's fair enough. I do have an idea about how to use a python script with Exim. I don't know enough to make it efficient, though. Maybe there's a problem with my python installation, or the way that I invoke it, but it seems that even a simple query takes four or five seconds to run:
rinka-12 # date ; /local/mailman/bin/list_members ian-test4 ; date Thu Jun 8 16:47:09 BST 2006 foo@example.ac.uk bar@example.ac.uk baz@example.ac.uk Thu Jun 8 16:47:13 BST 2006
But, it takes about 0.7 seconds to print "hello world", and truss shows a lot of files being opened just to get a list of members.
You should definitely use time(1) instead, but to open and print a 3 member list should be nearly instantaneous. FWIW, it only takes me about 1/2 second to do the same on a 2500 member list on fairly old h/w.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRImPMHEjvBPtnXfVAQICTQQArHcq2KOwZuFnRFj+gwJn+N2HAuNT7qwD epQwc+zEfrSJ8Q1VECMh+g9/nDSHI2h7sp10ST46NMaj60Fyhr7TahSrfNsEZzgQ 5jhuQAPA0wdKUFciCVIRNrrkJCLJLIMjQ6sJXDil2BVT858MlR+XvrH77cahw4HZ O/VCDexviSQ= =Id8s -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 07 Jun 2006 15:51:54 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
A better approach would be to structure the Mailman code in such a way that large parts of it can be used as a library, which could serve as the basis for sites writing their own MTA extension, or any other specialized Mailman-based application.
Perhaps. Even better would be to hold rosters in open databases. Exim, for example, can read sql, ldap, flat files and so on.
It's likely we'll do that too, to some degree, for MM2.2 (see my other response).
I don't think it's Mailman's job to examine the content of messages - that's the job of a spam or virus filter.
I agree.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIcY2XEjvBPtnXfVAQLI5QP/ZSTtijaiiFIDCsc9jiYsey3KnhdcNa7j k7K4PYKs4QGvvsq5vtnMokosEuJjsr9oVWDuq+esXMjEp52j0EH2XbOSORsb3DXz kHo6a4H5W2QU+DZPwcUikDRWGIc+bQPQAcsBKUzcDqGzRNLvNnIGAlQRa6dp4yKN NDcIipGKRoA= =o/ZY -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 9:26 AM -0400 2006-06-07, Barry Warsaw wrote:
I think that will be problematic, given the wide variety of MTA extension frameworks.
It's not just the MTA extension frameworks, it's also the myriad
of things that Mailman may choose to do or to look at when deciding what to do, based on content in the message.
I don't think it's feasible to completely re-write Mailman, or to
completely re-write the MTAs, so that each of them has a deep integral understanding of all the nuances and complexities of the work that is being done by the other.
Short of doing a rewrite on that scale, I suspect that we're
going to continue to have these kinds of problems for some time.
-- 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/>.
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 7 Jun 2006 12:24:26 -0500 Brad Knowles <brad@stop.mail-abuse.org> wrote:
It's not just the MTA extension frameworks, it's also the myriad of things that Mailman may choose to do or to look at when deciding what to do, based on content in the message.
I agree.
I don't think it's feasible to completely re-write Mailman, or to completely re-write the MTAs, so that each of them has a deep integral understanding of all the nuances and complexities of the work that is being done by the other.
Short of doing a rewrite on that scale, I suspect that we're going to continue to have these kinds of problems for some time.
There will certainly be limits to what you can do, but essentially the idea is that the MTA would be asking Mailman what it would do with a particular message. Kind of like the MTA calling out to SpamAssassin at various points in the SMTP protocol.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIcer3EjvBPtnXfVAQKK5wP/fjgFY1rBOErUXr1y154MUSylRYGzEu7K DqETUMsH/DuBB7Q+AUYxIeM0uS245p2jffGbWPI9pHl6Ysvb8NKo9tV+yMLlLaYs GhyUZC29fBejqQI5EwvmDlWHSfXwku8S4yk7CFS2jnkOyfme0XMBwKj8YcLZ06aL GdUMyKHq9XU= =/bQu -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 10:41 AM +0100 2006-06-07, Ian Eiloart wrote:
Even better would be to integrate Mailman into MTA's better, so that the MTA can use Mailman data to reject spam.
I think we've had this debate in the past. I don't think that's
possible, given the sorts of things that Mailman may do with messages, including taking different actions on different messages with the exact same combination of envelope sender and recipient, based on the values of other things in the headers (such as placed there by anti-spam/anti-virus scanning systems).
If you want to completely re-write your MTA so that it has a deep
understanding of all the internal workings of Mailman, feel free to go ahead and do that.
Otherwise, I suspect that we're going to continue to have this
kind of problem for quite some time.
-- 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/>.
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 6 Jun 2006 22:02:44 -0700 Mark Sapiro <msapiro@value.net> wrote:
I agree, but which is the best term to use? Reading the dictionary entries for "approve" and "accept", I think I like the former:
Actually, both terms are used on the radio buttons on the admindb page. "Accept" is used for held posts, and "Approve" is used for (un)subscription requests.
We could of course change the name of the held message radio button to "Approve", but then we'd have an inconsistency with "Add poster@example.com to one of these sender filters:", and if we changed that, would we also want to change the name of accept_these_nonmembers?
It seemed simpler to me to just make the template change I indicated in my prior reply.
I don't disagree with that, so go for it.
It's just that we'll be redesigning the web u/i as part of the Google SoC project (don't worry, it's not a forgone conclusion that that work will be integrated into the mainline release). As we redesign and rewrite, I think we should standardize on "Approve" for actions to be taken by the list administrator.
Ian mentioned that he thinks we should change "Reject" to "Bounce", but I'm not sure I like that. Rejecting a message or a subscription request is the action that the admin takes. Mailman's response to that rejection is return the original message wrapped in a response. The term "bounce" to me implies a more automatic return that happens at a lower level in the mail stack, and it might be confused with terminology in the bounce processing u/i.
So I think the following terms should be used consistently (I'm not suggesting a mass rewrite to adhere to this):
Approve Hold Reject Discard
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIbSsXEjvBPtnXfVAQKejwP/QPSup6mVwOezrMdYKly73z3QH3kbq3MN pzUanylMlhZ9mVB1AYfLLnqI4/ziWmNjkPRj31VtrGKVnTBGHLGAYCnmFB8E4S/P Zk5DvyG3fPj3VNCfFDN/UyKbaWMIe4tv7qHnS2C5xgE+pIBm00PPtmh9F0INElEi DwxEI348tIU= =b6Qu -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 7 June 2006 09:20:46 -0400 Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 6 Jun 2006 22:02:44 -0700 Mark Sapiro <msapiro@value.net> wrote:
Ian mentioned that he thinks we should change "Reject" to "Bounce", but I'm not sure I like that. Rejecting a message or a subscription request is the action that the admin takes.
OK, i'm talking about messages here, not subscription requests. As I understand the terms, a "reject" is an SMTP response to a remote server (or MTA) trying to send email. It means "I'm not accepting this email, you choose what to do with it". The sending MTA may choose to generate a DSN, and a DSN that reports a hard (5xx) rejection is often referred to as a bounce message.
With Mailman, rejection isn't possible. We've already accepted the message and queued it. When a Mailman list rule, or an administrator decides to "reject" a message, in fact they're choosing to send a DSN bounce message.
There's a REALLY REALLY REALLY important difference in the case of spam. Most spambots will ignore a reject and NOT generate a DSN bounce message. However, if you choose to bounce the message, then a DNS will be sent to an innocent third party. That's collateral spam, and it's a nightmare.
Unfortunately, RFC2821 says that you must generate such collateral spam, and that's why I want my MTA to be able to read Mailman's config - so that it can reject email properly at SMTP time.
Mailman's response to that rejection is return the original message wrapped in a response. The term "bounce" to me implies a more automatic return that happens at a lower level in the mail stack, and it might be confused with terminology in the bounce processing u/i.
So I think the following terms should be used consistently (I'm not suggesting a mass rewrite to adhere to this):
Approve Hold Reject Discard
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIbSsXEjvBPtnXfVAQKejwP/QPSup6mVwOezrMdYKly73z3QH3kbq3MN pzUanylMlhZ9mVB1AYfLLnqI4/ziWmNjkPRj31VtrGKVnTBGHLGAYCnmFB8E4S/P Zk5DvyG3fPj3VNCfFDN/UyKbaWMIe4tv7qHnS2C5xgE+pIBm00PPtmh9F0INElEi DwxEI348tIU= =b6Qu -----END PGP SIGNATURE-----
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a c.uk
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 3:46 PM +0100 2006-06-07, Ian Eiloart wrote:
Ian mentioned that he thinks we should change "Reject" to "Bounce", but I'm not sure I like that. Rejecting a message or a subscription request is the action that the admin takes.
OK, i'm talking about messages here, not subscription requests.
List moderators deal mostly with messages, list administrators
deal more frequently with things like subscription requests.
We need to distinguish here what we call what, in what context.
As I
understand the terms, a "reject" is an SMTP response to a remote server (or MTA) trying to send email. It means "I'm not accepting this email, you choose what to do with it". The sending MTA may choose to generate a DSN, and a DSN that reports a hard (5xx) rejection is often referred to as a bounce message.
Actually, no -- that would be a refusal. A rejection would be
something you would send after accepting the message initially, and then discovering that you could not deliver the message for some reason.
So, when it comes to spam, you want to refuse it and not reject it.
There's a REALLY REALLY REALLY important difference in the case of spam. Most spambots will ignore a reject and NOT generate a DSN bounce message. However, if you choose to bounce the message, then a DNS will be sent to an innocent third party. That's collateral spam, and it's a nightmare.
Yes, blowback is a problem. I'm not sure that anyone can resolve
this problem any time soon, however.
Unfortunately, RFC2821 says that you must generate such collateral spam, and that's why I want my MTA to be able to read Mailman's config - so that it can reject email properly at SMTP time.
See my previous responses. We may be able to teach the MTAs how
to read some of the databases that Mailman might be using when it would be making its decision to accept or reject the message, but I don't think it's going to be possible to teach the MTAs everything.
-- 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/>.
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 07 Jun 2006 15:46:56 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
OK, i'm talking about messages here, not subscription requests. As I understand the terms, a "reject" is an SMTP response to a remote server (or MTA) trying to send email. It means "I'm not accepting this email, you choose what to do with it". The sending MTA may choose to generate a DSN, and a DSN that reports a hard (5xx) rejection is often referred to as a bounce message.
With Mailman, rejection isn't possible. We've already accepted the message and queued it. When a Mailman list rule, or an administrator decides to "reject" a message, in fact they're choosing to send a DSN bounce message.
I think that's a good point. What's really happening is that the admin is disapproving the message and returning it back to the original sender. The question is, which term captures that better for non-techies (I think techies will get it either way). To me "reject" is better than "bounce". Has anybody seen any comments on this issue on mailman-users?
Using the term "bounce" here also has the possibility of confusion with the automated bounce processing system.
There's a REALLY REALLY REALLY important difference in the case of spam. Most spambots will ignore a reject and NOT generate a DSN bounce message. However, if you choose to bounce the message, then a DNS will be sent to an innocent third party. That's collateral spam, and it's a nightmare.
Right, but we're not talking about an automated process here, we're talking about the actions a list admin will take manually. I honestly don't think it's feasible for a list admin to be managing malware. Ideally, 99% of all malware should be filtered lower in the stack, before Mailman (and the list admin) ever sees it.
Of course, no filter is perfect, so if an admin does see spam, then she has the option of discarding it, which is why that operation has been optimized (Discard all messages marked deferred). Bottom line is that all malware that sneaks through whatever filters are in place should always be discarded, never rejected.
Unfortunately, RFC2821 says that you must generate such collateral spam, and that's why I want my MTA to be able to read Mailman's config - so that it can reject email properly at SMTP time.
Very soon now I am going to start work on a SQLite backend for MM2.2. If we're lucky, I'll be able to use something like SQLAlchemy or SQLObject which will buy you many other RDBMS's at the same time. Then it's just a simple matter of publishing the schema, right? <wink>
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIcYjXEjvBPtnXfVAQLj+gQAucBdCYrIwrGv1vVws2kvPNDRk3MFoQNY k1VOr2KQEgkqLE7tdkw4JZAMN22KxyCsIvs3TRwEQcrChU/kEySNqVJAZT2+KW5T 8NM4Y2fug53SGdjiv/C6Ig/wg3cXWseBC9+RnZdd/vKOC4XHXl5NM6dujkJn8fWy 7DauaMvv5qY= =ggpj -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 7 June 2006 14:18:52 -0400 Barry Warsaw <barry@python.org> wrote:
I think that's a good point. What's really happening is that the admin is disapproving the message and returning it back to the original sender. The question is, which term captures that better for non-techies (I think techies will get it either way). To me "reject" is better than "bounce". Has anybody seen any comments on this issue on mailman-users?
How about "return to sender"? That is what you'd say in the real world with snail mail. Better might be "return to purported sender" or even "return to some poor guy who knows nothing about this email" ;)
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 07 Jun 2006 19:44:51 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
How about "return to sender"? That is what you'd say in the real world with snail mail. Better might be "return to purported sender" or even "return to some poor guy who knows nothing about this email" ;)
:)
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIcfrnEjvBPtnXfVAQJ0tQP/Re/20m7I6W6/ooQY4MIjf6l9AtQTPJqu Fbue60fvRTlggfcmraQDulRN9aqoSo9UuykqlYDXyUN0LCLL3+34dqG/EFXQBge5 asL2XFZy7pARS90VTbutN5y5E3BfrhWSlfX250AWPbhN3H4LIhjaqJJQFPgi2QBm yJEY5N4mtTg= =9CRp -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:18 PM -0400 2006-06-07, Barry Warsaw wrote:
To me "reject"
is better than "bounce". Has anybody seen any comments on this issue on mailman-users?
Reject is the correct term. Ian misunderstood what you're
talking about, and got off on the wrong track.
-- 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/>.
![](https://secure.gravatar.com/avatar/fcc130bb83ad0cf89fd7bf173cd5523a.jpg?s=120&d=mm&r=g)
On Wed, 7 Jun 2006, Barry Warsaw wrote:
[...] It's just that we'll be redesigning the web u/i as part of the Google SoC project (don't worry, it's not a forgone conclusion that that work will be integrated into the mainline release). As we redesign and rewrite, I think we should standardize on "Approve" for actions to be taken by the list administrator.
[...] So I think the following terms should be used consistently (I'm not suggesting a mass rewrite to adhere to this):
Approve Hold Reject Discard
Throwing another item into the pot...
... on May 19th I started a thread "sender-based authorisation". In summary, this is intended as a defence against spoof. The incoming email would carry a header (of first line in body) of something like: Authorised: sender-pw
where "sender-pw" is associated with the (claimed) From-address. This is different from, but complementary to, "Approved: list-pw".
(See the thread itself for the gory detail.)
This thread seemed to be accepted in principle, and as a step towards the "to-do" item.
Given that I'm just about to start on implementing this, it would be nice to establish whether this sender-related word "Authorised" is the appropriate word, or if there is something better.
Locally, we need to get moving on implementing this concept. Whilst my local code might get heavily replaced as future versions of Mailman (re-)implement these ideas, it would nevertheless be useful, from the persepctive of our users, to get the terminology agreed early on.)
--
: 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. :
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
On Jun 8, 2006, at 7:39 AM, David Lee wrote:
Given that I'm just about to start on implementing this, it would
be nice to establish whether this sender-related word "Authorised" is the appropriate word, or if there is something better.Locally, we need to get moving on implementing this concept.
Whilst my local code might get heavily replaced as future versions of Mailman (re-)implement these ideas, it would nevertheless be useful, from the persepctive of our users, to get the terminology agreed early on.)
Seems reasonable (I should go back and re-read that thread, but I
think I get the gist of it), except for the English-speaking world's
inability to agree on the spelling of that word. :) In the US, it's
"Authorized".
I suppose you could accept both keywords.
-Barry
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 8 June 2006 12:39:22 +0100 David Lee <t.d.lee@durham.ac.uk> wrote:
The incoming email would carry a header (of first line in body) of something like: Authorised: sender-pw
where "sender-pw" is associated with the (claimed) From-address. This is different from, but complementary to, "Approved: list-pw".
That's neither approval nor authorisation, it's authentication - proving that the person who used the email address also knew the password associated with it. It's far better to insist on authenticated SMTP for ALL message submission.
Given that I'm just about to start on implementing this, it would be nice to establish whether this sender-related word "Authorised" is the appropriate word, or if there is something better.
I've had a look through that thread, and I'm not sure what you're trying to achieve. Generally, there are two aspects to deciding whether someone can post to a list: "authorisation" and "authentication".
Passwords are usually used for both, but it's far better to separate the functions. Knowledge of a personal password serves to authenticate you, but not to authorise you. Knowledge of a shared password is sometimes used for authorisation, but can't be used for authentication. Even for authorisation, passwords are extremely weak.
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 08 Jun 2006 15:26:25 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:
where "sender-pw" is associated with the (claimed) From-address. This is different from, but complementary to, "Approved: list-pw".
That's neither approval nor authorisation, it's authentication -
That's a good point.
Passwords are usually used for both, but it's far better to separate the functions. Knowledge of a personal password serves to authenticate you, but not to authorise you. Knowledge of a shared password is sometimes used for authorisation, but can't be used for authentication. Even for authorisation, passwords are extremely weak.
There has been some interest in the past on associating pubkeys with email addresses and using those to authenticate senders of signed messages. In the long run, that's probably a worthy avenue to pursue.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRIhBcnEjvBPtnXfVAQKZTwP/a0ULu7v8TQyrjAgI3Uj/znrsy+Kh24qp ilmE3Y/E9YXiYaSwpgdrLIyIH4zODXspML8l4jnscOBNexlpKNqfY4ZA9ky2oKoI x1YWDZmdVbrWyO5y3pN0bNOhQOkdiBqAs1STv5TP1VoN95eHQQrVlpGTMf6jTGll ZBl3kfV7xrU= =oLd8 -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/fcc130bb83ad0cf89fd7bf173cd5523a.jpg?s=120&d=mm&r=g)
On Thu, 8 Jun 2006, Ian Eiloart wrote:
--On 8 June 2006 12:39:22 +0100 David Lee <t.d.lee@durham.ac.uk> wrote:
The incoming email would carry a header (of first line in body) of something like: Authorised: sender-pw
where "sender-pw" is associated with the (claimed) From-address. This is different from, but complementary to, "Approved: list-pw".
That's neither approval nor authorisation, it's authentication - proving that the person who used the email address also knew the password associated with it. [...]
Thanks, Ian. I agree with that technical view. That suggests that the header (of first line of body) would need to be something like: Authenticated: sender-pw
To the average non-techie managerial type, what terminology (Authorised? Authenticated? etc.) is preferable?
[...] It's far better to insist on authenticated SMTP for ALL message submission.
That would, indeed, probably be the ideal. But that would itself mean that all paths by which the Mailman machine might be reached would have to be known to have an enforced mechanism for authenticated SMTP. (And what about (say) "cron" jobs generating email which might legitimately go through lists?)
An insitution's (university's) "smtphost" service might naturally restrict access to its own users and thus the authentication could use, say, its central NIS/AD/LDAP-like user-base. But its Mailman service might extend considerably beyond those bounds to include collaboration with other places, for which a much wider user-base would be needed. (Suppose, for instance, that this very "mailman-developers" list were hosted at your own university?)
Even if those problems could be overcome, one would still need to ensure that Mailman can know for certain that authenticated SMTP had been used. Which takes us off to another branch (about Mailan API, milters, etc.) of this fragmenting discussion!...
Given that I'm just about to start on implementing this, it would be nice to establish whether this sender-related word "Authorised" is the appropriate word, or if there is something better.
I've had a look through that thread, and I'm not sure what you're trying to achieve. Generally, there are two aspects to deciding whether someone can post to a list: "authorisation" and "authentication".
Passwords are usually used for both, but it's far better to separate the functions. Knowledge of a personal password serves to authenticate you, but not to authorise you. Knowledge of a shared password is sometimes used for authorisation, but can't be used for authentication. Even for authorisation, passwords are extremely weak.
Agreed. That earlier thread was simply setting the ball rolling.
The problem that precipitated that thread was an incident in which two emails went through our majordomo lists to the whole university (20,000 accounts), because those emails spoofed the "From" to match an entry in the "posters" file of those lists. So we are looking towards protecting these potentially massive distributions with a "From+verification" concept. (Hence our looking at Mailman, which looks much closer than majordomo to being able to offer that, especially as it is being actively developed.)
Thanks again.
--
: 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. :
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 8 June 2006 16:54:40 +0100 David Lee <t.d.lee@durham.ac.uk> wrote:
On Thu, 8 Jun 2006, Ian Eiloart wrote:
--On 8 June 2006 12:39:22 +0100 David Lee <t.d.lee@durham.ac.uk> wrote:
The incoming email would carry a header (of first line in body) of something like: Authorised: sender-pw
where "sender-pw" is associated with the (claimed) From-address. This is different from, but complementary to, "Approved: list-pw".
That's neither approval nor authorisation, it's authentication - proving that the person who used the email address also knew the password associated with it. [...]
Thanks, Ian. I agree with that technical view. That suggests that the header (of first line of body) would need to be something like: Authenticated: sender-pw
To the average non-techie managerial type, what terminology (Authorised? Authenticated? etc.) is preferable?
Not "Authenticated". That implies that authentication has already occurred. What you're doing is supplying a token to be used for authentication. So, "Authentication" would be better. Or even "Password".
Oh, and if it's an email header, shouldn't it be X-Authentication, or whatever?
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/fcc130bb83ad0cf89fd7bf173cd5523a.jpg?s=120&d=mm&r=g)
On Thu, 8 Jun 2006, Ian Eiloart wrote:
--On 8 June 2006 16:54:40 +0100 David Lee <t.d.lee@durham.ac.uk> wrote:
On Thu, 8 Jun 2006, Ian Eiloart wrote:
--On 8 June 2006 12:39:22 +0100 David Lee <t.d.lee@durham.ac.uk> wrote:
The incoming email would carry a header (of first line in body) of something like: Authorised: sender-pw
where "sender-pw" is associated with the (claimed) From-address. This is different from, but complementary to, "Approved: list-pw".
That's neither approval nor authorisation, it's authentication - proving that the person who used the email address also knew the password associated with it. [...]
Thanks, Ian. I agree with that technical view. That suggests that the header (of first line of body) would need to be something like: Authenticated: sender-pw
To the average non-techie managerial type, what terminology (Authorised? Authenticated? etc.) is preferable?
Not "Authenticated". That implies that authentication has already occurred. What you're doing is supplying a token to be used for authentication. So, "Authentication" would be better. Or even "Password".
I had picked on the past-tense terminology ("Authorised", "Authenticated", etc.) simply because the FAQ talks about an "Approved" (past tense) header. But I believe the code also accepts (present tense) "Approve". So I had antcipated that my proposal would be similarly tense-tolerant!
Oh, and if it's an email header, shouldn't it be X-Authentication, or whatever?
Two consistency trends pulling in opposite directions!
RFC-ish things suggest "X-Whatever:".
Mailman practice (the existing "Approved") suggests "Whatever:".
I was assuming I should follow the Mailman convention. (Whether the Mailman convention needs revision is another matter...)
--
: 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. :
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 9 Jun 2006 09:47:27 +0100 (BST) David Lee <t.d.lee@durham.ac.uk> wrote:
Not "Authenticated". That implies that authentication has already occurred. What you're doing is supplying a token to be used for authentication. So, "Authentication" would be better. Or even "Password".
I had picked on the past-tense terminology ("Authorised", "Authenticated", etc.) simply because the FAQ talks about an "Approved" (past tense) header. But I believe the code also accepts (present tense) "Approve". So I had antcipated that my proposal would be similarly tense-tolerant!
Password seems reasonable.
Oh, and if it's an email header, shouldn't it be X-Authentication, or whatever?
Two consistency trends pulling in opposite directions!
RFC-ish things suggest "X-Whatever:".
Mailman practice (the existing "Approved") suggests "Whatever:".
I was assuming I should follow the Mailman convention. (Whether the Mailman convention needs revision is another matter...)
Approved was chosen for compatibility with Majordomo, so there was a long tradition before us. Approve was added because so many people mistyped the original ;).
When blazing our own trails we should be more RFC compliant.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRImP03EjvBPtnXfVAQLt6wP/Y/a4OuZ8r8kRm/JSrAh8jFU1d4OhsQ5c l+s4kYYY3QE+IfGC92x+QRe6dVSp9jKEmtB08lA8pR2UvfYgc5xDMoZQ57ZYGyhA f48FwdkOCfmr5MZgpfsbrMiR2fIKrzXx8bT6Bo803Sz07/F1+KbYLAlq3BSe8/4d HP2qqroiZ5o= =zWMz -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 8 June 2006 16:54:40 +0100 David Lee <t.d.lee@durham.ac.uk> wrote:
[...] It's far better to insist on authenticated SMTP for ALL message submission.
That would, indeed, probably be the ideal. But that would itself mean that all paths by which the Mailman machine might be reached would have to be known to have an enforced mechanism for authenticated SMTP. (And what about (say) "cron" jobs generating email which might legitimately go through lists?)
Well, I guess that a typical Message Submission Agent would require authenticated SMTP *except* for a list of specificed (host IP, sender email address) pairs.
An insitution's (university's) "smtphost" service might naturally restrict access to its own users and thus the authentication could use, say, its central NIS/AD/LDAP-like user-base. But its Mailman service might extend considerably beyond those bounds to include collaboration with other places, for which a much wider user-base would be needed. (Suppose, for instance, that this very "mailman-developers" list were hosted at your own university?)
True. But are you really asking people to email secrets around? If you are, them I presume you're going to encrypt communication between your MTAs? Otherwise none of this is going to gain you anything.
I presume you're going to have Mailman remove those tokens before delivery? Otherwise spoofing will be just as easy as before. To be honest, I'm skeptical about all of this. Do you have a history of people spoofing to your lists?
Even if those problems could be overcome, one would still need to ensure that Mailman can know for certain that authenticated SMTP had been used. Which takes us off to another branch (about Mailan API, milters, etc.) of this fragmenting discussion!...
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 5:24 PM +0100 2006-06-08, Ian Eiloart wrote:
Well, I guess that a typical Message Submission Agent would require authenticated SMTP *except* for a list of specificed (host IP, sender email address) pairs.
Mailman is not an MTA or an MSA. It makes use of MTAs and MSAs,
but it is neither of these things itself. Therefore, it's not appropriate to ask David to fix MTA and MSA problems with respect to the code he's trying to add to Mailman.
True. But are you really asking people to email secrets around? If you are, them I presume you're going to encrypt communication between your MTAs? Otherwise none of this is going to gain you anything.
The only thing that's secret is the password used to authorize
their ability to post to the list.
I presume you're going to have Mailman remove those tokens before delivery?
I'm sure.
Otherwise spoofing will be just as easy as before. To be honest, I'm skeptical about all of this. Do you have a history of people spoofing to your lists?
Yes. Please re-read the thread. Using the "Approved:" mechanism
will prevent future spoofing, but brings along a whole host of other problems, such as having to share the list password with all the potential senders, which increases the security exposure due to the probability of the password being accidentally exposed. Then there is the issue of having to change the shared list password, and having to have everyone memorize the new shared password.
Using a per-sender password for the same mechanism will prevent
the spoofing, eliminate the probability of accidentally exposing the shared password, and make recovery from accidental exposure of a password much easier -- only the one user will be affected by having to change and remember the new password.
Some additional code will have to be added to handle the addition
of storing a per-user "Authorized" password, and a per-user authorization/approval mechanism (akin to the list of approved_nonmembers), as well as a cleanup mechanism to try and ensure sure that the new password doesn't get inadvertently exposed by Mailman.
But extending the existing "Approved:" mechanism is clearly the
way to approach this problem.
-- 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/>.
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 8 June 2006 13:40:03 -0500 Brad Knowles <brad@stop.mail-abuse.org> wrote:
At 5:24 PM +0100 2006-06-08, Ian Eiloart wrote:
Well, I guess that a typical Message Submission Agent would require authenticated SMTP *except* for a list of specificed (host IP, sender email address) pairs.
Mailman is not an MTA or an MSA. It makes use of MTAs and MSAs, but it is neither of these things itself. Therefore, it's not appropriate to ask David to fix MTA and MSA problems with respect to the code he's trying to add to Mailman.
I'm not asking him to do that. I'm talking about the ecology of the situation.
True. But are you really asking people to email secrets around? If you are, them I presume you're going to encrypt communication between your MTAs? Otherwise none of this is going to gain you anything.
The only thing that's secret is the password used to authorize their ability to post to the list.
Yes, that's the secret that I'm talking about.
I presume you're going to have Mailman remove those tokens before delivery?
I'm sure.
Otherwise spoofing will be just as easy as before. To be honest, I'm skeptical about all of this. Do you have a history of people spoofing to your lists?
Yes. Please re-read the thread. Using the "Approved:" mechanism will prevent future spoofing, but brings along a whole host of other problems, such as having to share the list password with all the potential senders, which increases the security exposure due to the probability of the password being accidentally exposed. Then there is the issue of having to change the shared list password, and having to have everyone memorize the new shared password.
Using a per-sender password for the same mechanism will prevent the spoofing,
Only if you ensure that the entire email transmission chain is encrypted. That's only possible if you know the sender is on-site (on your campus, in your company, whatever). If that's true, then you can rely on authenticated SMTP anyway.
eliminate the probability of accidentally exposing the shared password, and make recovery from accidental exposure of a password much easier -- only the one user will be affected by having to change and remember the new password.
Some additional code will have to be added to handle the addition of storing a per-user "Authorized" password, and a per-user authorization/approval mechanism (akin to the list of approved_nonmembers), as well as a cleanup mechanism to try and ensure sure that the new password doesn't get inadvertently exposed by Mailman.
But extending the existing "Approved:" mechanism is clearly the way to approach this problem.
-- Ian Eiloart IT Services, University of Sussex
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Ian Eiloart wrote:
--On 8 June 2006 13:40:03 -0500 Brad Knowles <brad at stop.mail-abuse.org> wrote:
Using a per-sender password for the same mechanism will prevent the spoofing,
Only if you ensure that the entire email transmission chain is encrypted. That's only possible if you know the sender is on-site (on your campus, in your company, whatever). If that's true, then you can rely on authenticated SMTP anyway.
This thread has probably been flogged to death already, and my initial deletion of this post was probably the correct decision rather than now resurrecting it from the archive for this reply, but I just want to add from the point of view of an interested observer, that I think we all know that sending the list password in a header of an unencrypted message is not very secure, and neither will this be secure against some kinds of attacks, but at least this proposal potentially exposes a less powerful password.
David is only trying to address a very limited kind of attack. He has multiple lists each with multiple authorized posters (but still a tiny fraction of the list membership - these are basically announcement lists). He is trying to protect the list from a list member's determining by observation who the authorized posters are and spoofing one of those addresses to mail to the list. This is a situation that has occurred for him (at least twice, I think he said).
If this were one list with one or two authorized posters, he could moderate everyone, and the authorized poster could use the Approved: header to post, but this is too cumbersome in his environment unless he made all the list passwords the same which is neither practical nor wise. So, he wants to extend the existing method to one which allows the authorized posters to post with a personal password.
We all know that this is not secure against all attacks, but David feels that it will be good enough for his situation.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 9 Jun 2006 06:59:24 -0700 Mark Sapiro <msapiro@value.net> wrote:
We all know that this is not secure against all attacks, but David feels that it will be good enough for his situation.
Which it probably is.
There have been others that have proposed registering pubkeys with email addresses and authenticating against message signatures. I think there may even be patches out on SF to support this with gpg. It seems to me that that's the right long term solution, although email PKI is (still) sadly poorly supported -- or understood by end users -- it seems.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRImSknEjvBPtnXfVAQJrCgP/f9oVtJmF/SDA/c/3jFi5ZJhqt3fRyA5X oK1Zx7aetmBCPVi14hIwD4PBGAAs8tBfdFwerrxFu8iC7Fjj5huflYi2j04yqN2/ 0rsYccVcbok8ci5lHFTukBpdR7O61Sshx1nlaUW4WxsWc6Zk644Hah4CoWSw9WeG Hp40QSw9Eck= =EH7y -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 11:06 AM +0100 2006-06-09, Ian Eiloart wrote:
Using a per-sender password for the same mechanism will prevent the spoofing,
Only if you ensure that the entire email transmission chain is encrypted.
Using the existing "Approved:" mechanism would also prevent the
spoofing, and would have the same exposures regarding encryption.
We're not trying to fix all of the security problems in Mailman,
we're just trying to take an existing mechanism (with known vulnerabilities) and extend that to work in a per-sender manner.
That's only possible if you know the sender is on-site (on your campus, in your company, whatever). If that's true, then you can rely on authenticated SMTP anyway.
Red Herring. We're not trying to fix all the possible security
problems in Mailman. That's a job for Barry, Tokio, Mark, and others.
-- 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/>.
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 9 Jun 2006 09:01:31 -0500 Brad Knowles <brad@stop.mail-abuse.org> wrote:
Using the existing "Approved:" mechanism would also prevent the spoofing, and would have the same exposures regarding encryption.
Actually, that might be the right approach here. Just use the existing Approved header, but instead of checking it only against the list admin password, check it against the user's password too. In fact do that first, falling back to the list admin password only if that fails.
No new header necessary. Think 'sudo'.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRImUoHEjvBPtnXfVAQLTQQQAsstiGXz2mfDtK5hBBJeOrwftrcs3+/xo QkNmjvSnVXyNqFMXQRhLcVB8o1PsJhPTTfXnDHRBwamK7Fow8RYlmNjF7g/QHMMu jo7Zv1JtR+IYVJPm16DmPPhZJHPlWtenB2eWbu2ZB4WjChrHYzDQFg6GXyiwFFSo lpMknsjNsMA= =3UHn -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 4:54 PM +0100 2006-06-08, David Lee wrote:
To the average non-techie managerial type, what terminology (Authorised? Authenticated? etc.) is preferable?
I think that the authentication thing is a red herring. Stick to
the original idea and make relatively minimal modifications to the code, and let Barry, Tokio, Mark, and others deal with the deeper technical and architectural issues that Ian is raising.
That would, indeed, probably be the ideal. But that would itself mean that all paths by which the Mailman machine might be reached would have to be known to have an enforced mechanism for authenticated SMTP. (And what about (say) "cron" jobs generating email which might legitimately go through lists?)
Which is part of why you shouldn't worry about trying to solve
this problem. With your original concept, you're not really opening any new security holes, and you shouldn't have to worry about trying to close those that already exist.
Just make sure that you put in the appropriate cleanup code into
place to remove the headers in question, as is done today for the "Approved:" header.
-- 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/>.
![](https://secure.gravatar.com/avatar/fcc130bb83ad0cf89fd7bf173cd5523a.jpg?s=120&d=mm&r=g)
On Thu, 8 Jun 2006, Brad Knowles wrote:
At 4:54 PM +0100 2006-06-08, David Lee wrote:
To the average non-techie managerial type, what terminology (Authorised? Authenticated? etc.) is preferable?
I think that the authentication thing is a red herring. Stick to the original idea and make relatively minimal modifications to the code, and let Barry, Tokio, Mark, and others deal with the deeper technical and architectural issues that Ian is raising.
That would, indeed, probably be the ideal. But that would itself mean that all paths by which the Mailman machine might be reached would have to be known to have an enforced mechanism for authenticated SMTP. (And what about (say) "cron" jobs generating email which might legitimately go through lists?)
Which is part of why you shouldn't worry about trying to solve this problem. With your original concept, you're not really opening any new security holes, and you shouldn't have to worry about trying to close those that already exist.
Just make sure that you put in the appropriate cleanup code into place to remove the headers in question, as is done today for the "Approved:" header.
Thanks, Brad, for this and your previous emails. Your have nicely grasped both sides:
(1) that this piece of string could be very long, and is an issue primarily for the Mailman development gurus in a global and relatively long timescale, context;
(2) that my own particular per-sender password proposal is intended to be a small, self-contained thing, modelled on the existing "Approved:", and with a very similar set of security issues (positive and negative), in a local, short timescale, context.
It's giving me the confidence to go ahead on this item, but I hope to keep in mind compatibility with (anticipation of) possible future developments.
Thanks again.
--
: 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. :
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 3:26 PM +0100 2006-06-08, Ian Eiloart wrote:
where "sender-pw" is associated with the (claimed) From-address. This is different from, but complementary to, "Approved: list-pw".
That's neither approval nor authorisation, it's authentication - proving that the person who used the email address also knew the password associated with it. It's far better to insist on authenticated SMTP for ALL message submission.
For the application that David is looking at, "Authorized" would
probably be the most appropriate term.
I've had a look through that thread, and I'm not sure what you're trying to achieve. Generally, there are two aspects to deciding whether someone can post to a list: "authorisation" and "authentication".
David is looking for a way to do a per-sender way of using the
existing "Approved:" mechanism, without having to share the list password across a large number of senders. Each user would get their own password that would achieve the same result.
But otherwise, there should be no additional security exposure,
and no change to the security threat model.
Passwords are usually used for both, but it's far better to separate the functions. Knowledge of a personal password serves to authenticate you, but not to authorise you. Knowledge of a shared password is sometimes used for authorisation, but can't be used for authentication. Even for authorisation, passwords are extremely weak.
This is a debate best reserved for discussing the entire
"Approved:" mechanism as a whole, as opposed to something that David should have to try to fix as a part of the extension work that he is looking at.
There are lots of deeper technical and architectural details here
that need to be addressed, and I think that's more appropriate to ask Barry, Tokio, and Mark to look into those issues as opposed to David.
-- 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 (6)
-
Barry Warsaw
-
Brad Knowles
-
David Lee
-
Ian Eiloart
-
John W. Baxter
-
Mark Sapiro