[Mailman-Developers] 2.1.8 documentation mismatch

[Ian Eiloart]

--On 8 June 2006 13:40:03 -0500 Brad Knowles <brad at 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