Re: [Mailman-Developers] Protecting email addresses from spam harvesters
On Tuesday 26 February 2002 16:52, Stephen J. Turnbull wrote: > >>>>> "John" == John Morton <[EMAIL PROTECTED]> writes: > > John> I find this feature is handy for small, private lists. > > Sure. I have a couple that could be handled that way, but we just > defaulted them all off. We post the names and addresses (they're > basically lists of project staff) on the home page, with mailtos and > fancy formatting, instead. When the staff forget who handles what, > they use that interface, just like the clients do. (It's voluntary, > they are warned about harvesting; nobody has refused yet.) Unless the membership data that mailman stores has suddenly got a lot better documented since I last looked, I assume you're basically maintaining a separate list for your roster. I'd rather have one source of member data. > John> I'd rather it was still around and just disabled by default > John> with warning stickers all over it than we dumb down mailman > > To me, it's not really an issue of dumbing down. It would be easy > enough to do this with a separate app, so the question is "should a > deprecated feature continue to encruft MM?" I agree that when Mailman has a nice, well documented data schema and a datastore that accepts concurrent client access, then this sort of feature ought to be deprecated from the MM core. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Protecting email addresses from spam harvesters
On Tuesday 26 February 2002 15:47, Chuq Von Rospach wrote: > On 2/25/02 6:38 PM, "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote: > > BAW> 5) list rosters > > > > I don't know of any lists where these are available to the members, > > let alone the public. > > You know, now that I think about it. Wihle I think Mailman now has this > turned off by default (does it? If not, it should...), perhaps it's time to > just make the option dead and buried, so that na�e list admins don't have > the ability to open it up any more... I find this feature is handy for small, private lists. I'd rather it was still around and just disabled by default with warning stickers all over it than we dumb down mailman to Fisher Price levels just in case some twit exposes people to a greater likelihood of receiving junk mail. Perhaps it can be made to be disabled in a site-wide fashion? John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Friday 22 February 2002 18:58, Dale Newfield wrote: > On Fri, 22 Feb 2002, John Morton wrote: > > Ok. Show me a solution > > The point is that adding layer after layer of temporary solutions doesn't > add up to an actual solution any more than not adding those layers. All > it does add is more complexity to manage, more code to write and test, > more annoyance to anyone trying to use the system, and more potential > points of failure. This depends on just how temporary your 'solution' turns out to be, and it's level of complexity and usability. I don't think anyone has really advocate any really kludgy hacks so far. > Separate archives (public stripped of anything that > looks like an email address, private unmodified), and an equivilant "give > me archive access" path to the subscription path (through email) as has > been suggested seems to be the best solution yet. Not bad; it looks fairly easy to implement. I'd build the archive access to be just like regular list access, except delivery is turned off by default, to keep it simple. The problem is that if you accept that those nefarious agents of mass email will start auto-joining lists and plunder the private archive and message feed for addresses sometime in the future, then you have to implement another layer of hackery to detect and block that sort of thing. Does that make your suggestion any less of an actual solution? :-) I'd still go as far as adding per user configurability for address display so people can adjust the option to suit there own level of hysteria. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Friday 22 February 2002 18:36, Dale Newfield wrote: > On Fri, 22 Feb 2002, John Morton wrote: > > The best we can do here is implement something simple now that gets the > > job done, and continuously test it to see if it's still good enough. > > When it's not, we build another countermeasure. > > I completely disagree. You argue for job security. I argue for better > software. Temporary solutions are not solutions. Ok. Show me a solution that will protect list administrator addresses and publicly accessable list archives from email harvesting, while allowing list subscribers and members of the public the ability to contact the list admin in the event of a list related problem and allowing them to contact an individual personally in response to some message in the archive. The solution must not penalize text only web browser users, or the disabled, nor should it open up any other vectors for unsolicited mass emailing. I'd really like to see one. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Save the world from spam
On Friday 22 February 2002 16:36, Chuq Von Rospach wrote: > > Excellent. Would you mind publishing an analysis so we can start making > > some informed decisions as to what methods are effective? > > Oh, that's easy. I haven't found evidence of any harvesting. I've also been > able to find evidence of harvesting from OTHER site's lists on at least > three occcasions where people complained to me my lists were being > harvested. And those lists had publicly accessable archives with no address mangling? > Understood. But -- there are going to have to be some compromises and > tradeoffs made. The whole discussion was intended to look for them, because > I don't believe you can have all of that successfully. Something will have > to give. Yep. Almost time to go back through the thread so far and summarize the options that have been discussed, I think. > > That's because email addresses aren't secrets. If you can think of a > > better method than address mangling or hiding behind web forms, do tell. > > Personally, I'm willing to consider those good enough for the time being. > > You know, now that I think of it, there's another approach: you don't get > the admin's email address until you authenticate. Then you get it. If > you're a list subscriber, you authenticate to the same level as the list is > authenticated. If you're not, Mailman sends you an e-mail with the address > in it (or FROM the address, so you can merely reply to it). No valid email > address, no access to the admin. And if you do that, you can also set up a > blackhole for known abusive addresses, shutting out the trolls.. > > Thoughts? I think the list admin address is exposed to subscribers in the welcome message and monthly reminders already; I presume you mean that to see a web page with it, you'd have to log in first. I think the problem with this is the most likely reason that someone would email the admin if they're subscribed is because they can't log into the site to change there settings, see the archive and so on, or they're trying to subscribe to the list but the email confirmation process is failing for some reason (this has happened to me on a couple of occasions due to MTA wierdness at the list end). Naturally, failures anywhere before the email confirmation process couldn't be reported, either. This one doesn't look to be any better than the web form, except that it might work in an email only environment. Perhaps both? John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
[Mailman-Developers] Save the world from spam
On Friday 22 February 2002 14:36, Chuq Von Rospach wrote: > On 2/21/02 5:25 PM, "John Morton" <[EMAIL PROTECTED]> wrote: > >> Nobody has bothered to do this YET. That we know of. But the spamhacks > >> are evolving rapidly. > > > > Well, let's find out shall we? Set up a honeypot private list containing > > a collection of free mail accounts, then cycle through the account every > > week checking for spam and making some postings to keep the traffic up. > > Enough with the armchair anthropology, already! > > Um, John? I've been doing that for months. It's a standard tactic I use to > test for archive harvests. No offense, but given I'd already thought of the > "subscribe and harvest" attack, wouldn't you think I also would have looked > for ways to detect it? Excellent. Would you mind publishing an analysis so we can start making some informed decisions as to what methods are effective? > I just don't like to talk about it. One has to think the harvesters are > listening. I don't like giving away too many secrets -- but at the same > time, it's something we have ot share ideas and concepts over... Wah! Spammers aren't the NSA/Red Menace/Grey Aliens. I think we can and should be discussing what they're acutally up to if we want to find good methods of dealing with it. Don't get me started on full disclosure :-) > > I think we all need to take a deep breath and say 'It's only junkmail'. > > They're not spending up large on your credit card or pouring sugar into > > your gas tank. > > I won't argue. I expect Jay will pop up shortly and do it for me. Which is, > I think, the point. Just because you aren't too sensitive to the mail > doesn't mean others aren't -- so we have to keep all of the views in mind. > And this is a case where I actually side more on your view, but still > understand the need to manage this for those that don't have my tolerance > level. As a list admin, I'd like to inform my subscribers about their level of exposure, and empower them to decide whether there email address will appear in the archives, and how. I'd also like to keep the signal to noise ratio on the admin address in a tolerable state without running too great a risk of throwing the baby out with the bathwater by dropping too many legitimate crys for help along with the processed pig product. I'd like it if mailman would help me out with these things, but I don't want to _have_ to use ADA/text only browser busting jpeg addresses and reverse turing tests, and I don't want to have to use web form access to addresses in the archive as I won't trust that code until a lot of security geeks have looked it over. > Only if you don't change them. Making them standard might not be a good > idea, once they're hidden behind contact forms. Check. Add that to the admin form wishlist. > > The problem with obscurity as a security tool is that it's not reliable. > > It only works until it fails, and then you can't fix it. And I've found it > invariably fails at 10PM on a Friday night, when you're about to leave for > the weekend -- unless it's 2PM on a Thursday with a Friday deadline. As I said, obscurity works if you can replace one instance of compromised obscurity with another one fairly quickly. Works for passwords, and it can work well enough for this application, too. > > Obscurity is useful. In our case, it's the only prevention tool we have. > > I'm not sure obscurity is the right word. Most of what we're talking about > is more of a cloaking effort. That's because email addresses aren't secrets. If you can think of a better method than address mangling or hiding behind web forms, do tell. Personally, I'm willing to consider those good enough for the time being. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Friday 22 February 2002 11:20, Chuq Von Rospach wrote: > On 2/21/02 2:00 PM, "John Morton" <[EMAIL PROTECTED]> wrote: > > I think we're really getting into wild speculation territory here. No one > > will bother hacking the code to automatically get new free mail accounts > > [...] > > Nobody has bothered to do this YET. That we know of. But the spamhacks are > evolving rapidly. Well, let's find out shall we? Set up a honeypot private list containing a collection of free mail accounts, then cycle through the account every week checking for spam and making some postings to keep the traffic up. Enough with the armchair anthropology, already! > More rapidly than the anti-spam hacks in many ways. I > sure wouldn't depend on them never doing this. I agree. That's because we're in an arms race here. Email harvesters are probably evolving faster than the countermeasures because of the tendency to deploy one countermeasure and forget about it. > I'm not sure what we'd do if > they did, either, but some aspects of it have happened to me in small ways, > just not from the major spamhacks. So basically you need to deploy a countermeasure, monitor it's effectiveness, and deploy another when it fails. Repeat for as long as you consider it important, or can tolerate not resorting to private archives, and establishing better trust relationships with the subscribers. > Fact is, if they want your subscribers, they can get them. Or more > correctly, your subscribers that post -- but if everyone lurks in fear, why > hav a mail list? I think we all need to take a deep breath and say 'It's only junkmail'. They're not spending up large on your credit card or pouring sugar into your gas tank. > The question is, what can we do to make it as tough as we > can for the spammers, without screwing it up for us (as admins) or our list > users. If only because the harder we make it for them to hack us, they more > likely they'll go somewhere else that's easier to crack... Right. So let's go with contact forms for list admins, and slashdot style, per user configurable address mangling for the archives. Let's do a little research into the ongoing effectiveness of these methods, too, so we know when it's time to implement something more expensive. > On the other hand, if Mailman does become the de-factor mail list standard, > or one of a couple of key list servers, you can bet the spam ahcks will > focus on it, because if they can crack the code, they can crack a LOT of > lists really fast. So we have the potential to become a target of our > success, and we should be aware of that. It's probably one of the top three or four already. Do listserv and majordomo admins have a major spam problem? The two above techniques will work fine. If I, as a list subscriber feel that the signal to noise ratio is dropping, I can change my address mangling scheme. Hiding the otherwise web published list admin address behind a form should just about protect it by that vector for all time as it will just never be worthwhile hitting a collection of forms when you can get vast lists of addresses elsewhere. (of course you have to publish the mailing list address, so you can deduce the admin address from that...:-) > But what happens when other groups get smart too, and clean up the low > hanging fruit? Depending on that to protect us is a false security, > basically no better than the old security-by-obscurity issue. Given port > scanners and the like, there IS no obscurity from the crackers any more. The problem with obscurity as a security tool is that it's not reliable. You may as well assume that one day your secret will be out, so the decision as to where and how to deploy it needs to be made based on the cost of obscuring, the cost of having the information revealed, the cost of reimplementing the system to replace the obscured part, and the size of the window of opportunity created before you can fix the problem. Passwords, passphrases, keys and so forth are all examples of security through obscurity. They work because it's very easy to replace them; they work most effectively in systems that are good at detecting that they've been compromised. Striping identity strings from network daemons is another security through obscurity technique. No one would rely on it to protect them, but it does make the job harder for attackers and easier for the defenders - they have to try a lot more things to detect what software is behind the port, or just brute force it with known attacks, greatly increasing the detection and response time available to defenders. Obscurity is useful. In our case, it's the only prevention tool we have. Email addresses are not secrets, but we still want to protect them
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Friday 22 February 2002 05:28, Dale Newfield wrote: > On Thu, 21 Feb 2002, Damien Morton wrote: > > Making a private archive available to those who are list members > > I haven't commented on this before, but the reason I find this solution > lacking is that most mailman lists (in my experience) don't require list > admin permission to join. If this is the hurdle, as a spammer I'd just > create a hotmail account that I can automatically subscribe to any mailman > mailing list, and then gain access to the honeypot. I think we're really getting into wild speculation territory here. No one will bother hacking the code to automatically get new free mail accounts (this requires staying up to date with some range of mail service's cgi interface for their join function), automatically join any mailing list they find (same problem as before, coupled with having an automated way of finding lists to plunder), then going through the usual email confirmation step (ok, not hard if your mail service lets you pop mail from them). No one is going to bother implementing and maintaining this attack while they can grep addresses straight out of Usenet, off the web and out of DNS. If at some point in the future, those sources dry up, then it might be time to rearm. If there's compeling evidence that private archives and voluntary address obfuscation methods are failing, then it's time to rearm. But let's just keep in mind that this will always be an arms race, and that at the end of the day, it's only junk mail. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thursday 21 February 2002 18:41, Chuq Von Rospach wrote: > There is some validity to the "the club" mentality, of "we don't have to > fix it, we only have ot make it difficult enough to convince them to annoy > someone else". But if we assume we're building the New Defacto Standard > Listserver for the Internet here with mailman, that strategy fails, because > if we succeed, then it becomes worth their time to find the anti-Club. > Security by obscurity only works if you're really obscure, which implies > failure of the software to thrive. I'm not interested in that (and even > then, you aren't guaranteed success by being obscure). > > Another way of looking at it is "I don't have to outrun the lion. I only > have to outrun you" -- but that doesn't work if the lion is infinitely > hungry and doesn't get tire.d Which defines a spambot. Indeed. Email addresses aren't secrets - even more so than credit card numbers and biometric data - and the attackers have more than enough resources to seek them out. > I'm more and more ocnvinced the answer is simply putting admins behind a > web form, and telling site admins to publicize an emergency address (like > postmaster), and putting up a watcher on the system to set off alarms when > it breaks. For the admin addresses, I'd agree with you. Building up a document of pointers to good spam filtering tools couldn't hurt either. For archives that aren't behind a login, I think slashdot style obfuscation is the best we can do. The list admin can pick the default obfuscation scheme or none at all. Users who want there email address out there for whatever reason can do so, and rely on their 'War and Peace' spam filters to keep the noise down, while other folks can opt in even further and replace the obfuscated email address with some useless string. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thursday 21 February 2002 18:08, Dale Newfield wrote: > On Thu, 21 Feb 2002, John Morton wrote: > > It's a test to find out if the agent that requested the page is human or > > some bot of some sort. > > Assuming you can build such a test. Good luck. Building a good one is tricky. It depends on your model of the attacker, and while I've seen some wild speculation of the capabilities of email address harvesters, I don't have any hard facts about the cost/benifit equations they use. > > If the question and answer can be arbitary on a site by site, or better, > > hit by hit basis, then it becomes infeasible to build a spambot to enter > > such sites. > > If it's arbitrary, it's generated by some algorithm. If it's generated by > some algorithm, I just need to figure out the algorithm and I can always > get it. Arbitary as in 'doesn't have to be fixed'. Allowing the site admin the ability to build there own set wouldn't have to involve an algorithm (though I'm spliting hairs, really; I don't think this is a workable idea, either). > > I'd pregenrate them, give them an arbitary name and store a dictionary > > mapping email addresses to the image for page building purposes. > > > > > Once you've got that database, why not > > > just have that database front a web form instead of displaying the > > > address? > > > > I'm not sure what you mean by this. Can you explain? > > If you've got a database mapping arbitrary number/name/string to an email > address, then why not just have a web form that sends mail to that address > knowing only the arbitrary value (and never divulge the email address)? "What if the form breaks down?" :-) Actually, the reason not to use it is that it can be used to spam anyone who's id mapping you can grab from the archive! > > I'd prefer a slashdot style per user 'display address' option. > > I don't believe any system like slashdot's is worth the time to implement, > since it is just as easily broken, and now you've got more useless stuff > for every single user to manage. You've got three statements here, I'll address them one at a time: 1) 'I don't believe any system like slashdot's is worth the time to implement' How hard is it, really. All we're looking at is adding an extra field to the each member record, to the forms for managing user settings, a method to generate a default obfuscation and anther one to substitute addresses in the archive. 2) 'since it is just as easily broken' I never bothered to obfuscate my address, and while I seldom post, I hardly ever recieve spam either (and my address is attached to all sorts of things that are more likely to be harvested). The best we can do is come up with some 'good enough' solutions, and one that offers a user the opportunity to have their address displayed as 'no spam please' is about the best I can think of. Rather than have the whole list exhale great gouts of hot air about what obfuscation methods are broken or not, why don't we do an experiment? Someone should sign up for a couple of email addresses at a free mail service, subscribe to slashdot and post to several stories with each over the month. One account can use their raw email address in each posting, and the other can use some obfuscation method. Then, as the weeks tick by, we can actually see just how useless, or otherwise, obfuscation really is. 3) 'and now you've got more useless stuff for every single user to manage.' If 16 million people can operate the Hotmail UI, I think mailman list users can handle another text field. Especially if it's already filled out for them. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
On Thursday 21 February 2002 17:15, Dale Newfield wrote: > On Wed, 20 Feb 2002, Damien Morton wrote: > > Web Forms for contacting the admin cold. If the admin replies, you can > > continue the conversation via email. > > Right, assuming the web form doesn't break. Monitor the form. Your monitoring tools should be telling you when bits of your site break before users have a need to report the problem. > > Private and Public views of the archives. > > > > Private archives are restricted to list members and those that can pass > > a reverse turing test. > > People keep using this term, but I'm not sure what they mean, or if I > trust that they'd be so reliable... It's a test to find out if the agent that requested the page is human or some bot of some sort. In order to progress past the form you have to enter something into the box as a reply to some text in the form. If the question and answer can be arbitary on a site by site, or better, hit by hit basis, then it becomes infeasible to build a spambot to enter such sites. > > Public archives render all email addresses as jpegs. > > If they're automatically generated, it'd be easier to create pngs or gifs, > or lots of other formats than jpgs. Think about this, though--how do you > actually generate the images and serve them properly without either > including the email address in the html code anyway (so the img request > specifies what image to generate), or building a whole database mapping > arbitrary numbers to email addresses (so they can either be generated on > the fly or stored pre-generated). I'd pregenrate them, give them an arbitary name and store a dictionary mapping email addresses to the image for page building purposes. > Once you've got that database, why not > just have that database front a web form instead of displaying the > address? I'm not sure what you mean by this. Can you explain? (Not that I think image addreses are a good idea for all the reasons you mentioned earlier. I'd prefer a slashdot style per user 'display address' option. It can be obfuscated by default, but it allows the user to restore there actual address, or render it unrecognizable depending on there personal spam tolerance threshold.) John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on posted addresses...
On Tuesday 19 February 2002 04:21, Jay R. Ashworth wrote: > On Sun, Feb 17, 2002 at 09:37:31PM -0800, Chuq Von Rospach wrote: > > > I never understood why mailman wasn't changed to allow users to change > > > there own addresses years ago. Being able to add valid receiving > > > addresses would help, too. That is also something mailman can help > > > with. > > > > All it takes is code. Volunteering? (grin) > > Because there's not a sufficiently strong method of authenticating that > the person trying to change the address is actually the *user*? No, it just involves squashing the two actions a user needs to take into one, more obvious action - rather than subscribe a new address, confirm it, then delete the old address and confirm it, you change the address (keeping the settings), and confirm both dropping the old address and sending to the new one as a pair of emails. Iff both confirmations succeed, the address changes, otherwise it stays as it was. Adding other valid sending addresses will also require an email confirmation action. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on posted addresses...
On Monday 18 February 2002 17:56, Chuq Von Rospach wrote: > On 2/17/02 8:39 PM, "John Morton" <[EMAIL PROTECTED]> wrote: > > If they can set up admin specific accounts that redirect to /dev/null, > > then they can set up procmail to drop HTML mail, and say they're doing so > > anywhere they're advertising the admin email address. That would filter > > 90% of the spam they're likely to recieve for a start. > > And a bunch of legitimate mail, since more and more users are using HTML, > and more and more systems are set up to send it by default. Not a solution, > unless you primarily admin to geeks. It's better than > /dev/null :-). Let's face it - if you're going to publish an admin address to help the lowest common denominator of netizen, then you can't munge it, so it will get spam. Mailman doesn't provide filtering for email accounts, nor should it. So the best you can do is advise admins of good filtering software, and best practice ways of using it. Droping html mail happens to be one practice that works pretty well for a given type of list membership. > > Something that mailman can help with, though - assistance in filtering > > based on whether the sender is joined to a list that the admin account is > > tied to. Just a simple boolean is/isn't on the list should be enough; > > leave the policy to the delivery agent/user. > > And how odes that does the "I'm trying to subscribe and can't make it > work!" It doesn't. But you can put all the requests from list members into another folder, or give them a higher priority. It all helps. If you need to prioritize subscription problems then you could use a feedback form, and maybe Mailman should provide one. > "My stupid IS department changed my address again and I need > help!" problems? I never understood why mailman wasn't changed to allow users to change there own addresses years ago. Being able to add valid receiving addresses would help, too. That is also something mailman can help with. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on posted addresses...
On Monday 18 February 2002 17:02, Chuq Von Rospach wrote: > On 2/17/02 7:48 PM, "Larry McVoy" <[EMAIL PROTECTED]> wrote: > > Second, the point is that even if mailman is 100% perfect, it's not > > at all clear that that would result in even 1% less spam hitting home. > > If that's even remotely close, then it seems like efforts could be better > > spent on screening technology. > To me, it's more an issue of "we can't be part of the problem", not "we're > the solution". I have a couple of admins who want their addresses removed > from all public pages -- which I've refused to do, because I think the need > for access by a user in trouble trumps the admin's privacy. I think at > least one of those admins has solved it by setting up an admin-specific > account, and redirecting it to /dev/null, which, if I ever definitely catch > him doing so, will get him in trouble... If they can set up admin specific accounts that redirect to /dev/null, then they can set up procmail to drop HTML mail, and say they're doing so anywhere they're advertising the admin email address. That would filter 90% of the spam they're likely to recieve for a start. Something that mailman can help with, though - assistance in filtering based on whether the sender is joined to a list that the admin account is tied to. Just a simple boolean is/isn't on the list should be enough; leave the policy to the delivery agent/user. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Mailman + PostgreSQL
On Wed, 21 Feb 2001 08:32:44 -0500 Chris Ryan <[EMAIL PROTECTED]> wrote: > Hello all, > > I've been using Mailman on our web site for open source development of > "serious business software." http://www.greatbridge.org/. We are > interested in seeing Mailman have a PostgreSQL database back end (and > further in the future PHP front end web tools.) I have been given > permission to start working on this as soon as I have completed my > current project (should be done this week). > > I've started to familiarize myself with the general flow of Mailman. I > have not had a chance to get into the current data handling classes but, > correct me if i'm wrong, I believe modifying the code to use a database > should be fairly contained. In the process of doing this I want to do > everything in a such a manner that is best for contributing back to the > Mailman project. > > Any feedback anyone can offer on this subject would be wonderful. > Thanks in advance. Rather than hack in postgreSQL support directly, it's probably a better idea to wrap the whole data storage system in an abstraction layer, provide a couple of standard implementations (ie pickled objects and the postgreSQL system you're looking into to) and allow people to integrate their own storage system to suit their needs. Personally I want to place Mailman's data into a ZODB so I can get seemless Zope intergration. Zpatterns might be a good place to start, as far as a data abstraction layer goes. http://www.zope.org/Members/pje/Wikis/ZPatterns/HomePage John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re[2]: [Mailman-Developers] Big checkins a'comin'!
On Thu, 15 Feb 2001 15:12:49 +1100 Andrew McNamara <[EMAIL PROTECTED]> wrote: > >JM> Might as well add code to convert the password from the > >JM> depreciated form to the current default if one of the fallback > >JM> methods succeeds, then set the fallbacks to cascade over > >JM> crypt, MD5 and plaintext. This way, you can quitely change to > >JM> a more trusted hash should your current default eventually be > >JM> broken. > > > >No can do. crypt()'s a one-way hash and Mailman doesn't store the > >cleartext password (for the list), so there's no way to recover it in > >order to convert. > > You could convert on the fly: when the user validates correctly, you > temporarily have the clear-text password, and could convert it from > crypt to md5 at this point. That's what I meant :-) Not my day for clarity, it seems. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re[2]: [Mailman-Developers] Big checkins a'comin'!
On Wed, 14 Feb 2001 22:59:15 -0500 Barry A. Warsaw <[EMAIL PROTECTED]> wrote: > > >>>>> "JM" == John Morton <[EMAIL PROTECTED]> writes: > > JM> Might as well add code to convert the password from the > JM> depreciated form to the current default if one of the fallback > JM> methods succeeds, then set the fallbacks to cascade over > JM> crypt, MD5 and plaintext. This way, you can quitely change to > JM> a more trusted hash should your current default eventually be > JM> broken. > > No can do. crypt()'s a one-way hash and Mailman doesn't store the > cleartext password (for the list), so there's no way to recover it in > order to convert. Indeed - that's why I was talking about doing it when one of the fallback methods for authenicating the password succeeds. The list admin has just supplied you with a password, and you know it's correct because you've just successfully compared the crypted version (or whatever) with the one stored. Might as well take the default hash of the password and store that at the same time. > I've thought about storing the list password in the clear. This would > allow a mail-back option for list owners, but requires for stricter > security in the file system (since the list passwords can be snooped > from the database). Have the site administrator make the call by allowing them to set the default password storage method themselves, and if it happens to be set to plain text, have the mail-back option available. This might require tagging the passwords with their method of encoding, but it should be possible to convert existing passwords without too much trouble. Of course, the documentation should recommend SHA-1 is (probably) better than MD5, which is better than crypt, and that a plaintext password installation should take special care to protect the mailman install from snooping. John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Big checkins a'comin'!
On Wed, 14 Feb 2001 21:57:12 -0500 Barry A. Warsaw <[EMAIL PROTECTED]> wrote: > Hmm, other than that, there's a few more bounce detectors. Also, I'm > ditching the crufty md5/crypt munging of passwords and opting for an > sha1 hash always. However, to support backwards compatibility > (i.e. the list passwords are not kept in plain text), if the sha hash > of the response doesn't match the challenge, we try crypt as a > fallback. Might as well add code to convert the password from the depreciated form to the current default if one of the fallback methods succeeds, then set the fallbacks to cascade over crypt, MD5 and plaintext. This way, you can quitely change to a more trusted hash should your current default eventually be broken. John. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
