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

-----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-----

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/>.

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/>.

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/>.

-----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-----

-----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-----

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/>.

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/>.

--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

-----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-----

-----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-----

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. :

--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

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. :

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!

1. RFC-ish things suggest "X-Whatever:".

2. 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. :

--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

--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

-----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-----

-----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-----

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. :