--On 8 June 2006 13:40:03 -0500 Brad Knowles <[EMAIL PROTECTED]> 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 _______________________________________________ Mailman-Developers mailing list [email protected] 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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
