[Mailman-Developers] 2.1.8 documentation mismatch

Brad Knowles brad at stop.mail-abuse.org
Thu Jun 8 20:40:03 CEST 2006

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

More information about the Mailman-Developers mailing list