On Thursday 27 November 2003 11:05 pm, Barry Warsaw wrote:
> On Fri, 2003-11-28 at 06:26, Colin Palmer wrote:
> > (then you just need to add an ACL to the webserver to stop someone
> > downloading the listname.mbox file that has all the unmunged addresses
> > still in it)
>
> I'd consider turning t
On Thu, 2003-11-27 at 17:07, Brad Knowles wrote:
> At 1:12 PM -0500 2003/11/27, Barry Warsaw wrote:
>
> > - Obviously you're going to do personalized deliveries, so for any such
> > list you'll probably want to disable digests.
>
> Actually, you can encrypt the message once, to each of th
On Fri, 2003-11-28 at 06:26, Colin Palmer wrote:
> (then you just need to add an ACL to the webserver to stop someone
> downloading the listname.mbox file that has all the unmunged addresses
> still in it)
I'd consider turning this off for 2.1.4 if people agree. Perhaps making
it available only
On Thu, 2003-11-27 at 14:19, Chuq Von Rospach wrote:
> On Nov 27, 2003, at 10:32 AM, Barry Warsaw wrote:
>
> > We don't need to get into lengthy language wars here, but I submit that
> > there's no practical difference in performance between Python and Perl,
> > especially in the problem domain th
On Nov 27, 2003, at 2:26 PM, Colin Palmer wrote:
re.sub('@', _(' at ') with re.sub(r'([EMAIL PROTECTED])[\w\.-]+', r'\1...'
which achieves a similar effect with ARCHIVER_OBSCURES_EMAILADDRS
turned
on.
which is a no-op, since spambot's learned how to de-obfuscate that
stuff years ago. False sense
On Fri, 2003-11-28 at 06:08, Terri Oda wrote:
> So, is anyone working on this *within* pipermail? I know there are great
> alternative archivers out there, but Mailman still winds up with a bad
> reputation if the default isn't very secure. Maybe for 2.2 we could have a
> "completely obscure arch
At 1:12 PM -0500 2003/11/27, Barry Warsaw wrote:
- Obviously you're going to do personalized deliveries, so for any such
list you'll probably want to disable digests.
Actually, you can encrypt the message once, to each of the keys
of each of the people on the list. You don't have to do multip
On Nov 27, 2003, at 10:32 AM, Barry Warsaw wrote:
We don't need to get into lengthy language wars here, but I submit that
there's no practical difference in performance between Python and Perl,
especially in the problem domain that Mailman addresses.
Sorry, given that Mailman is almost always rate
On Nov 27, 2003, at 9:52 AM, Terri Oda wrote:
Of course. We should remember that *that's* the reason not to do
turing
tests.
It's a great example of people solving problems before they actually
define them, and throwing resources at symptoms, not really solving
what's at root cause.
Now some
It's not a security issue. It's a privacy issue. Very different beasts.
Very important beasts, but the only thing they have in common is the
number of legs they have.
The underlying issue is similar to many bugtraq issues: what used to be
a common, acceptable coding practice no longer is. But m
Im not what you could consiter a power user as far as Mailman is
concerned, but it is my understanding that there is more then one way
for messages to get into the 'admindb' (if thats what the
to-be-moderated queue is called). Being flaged as spam would be another
way to enter that queue. How it g
On Wed, 2003-11-26 at 05:36, Bernhard Kuemel wrote:
> It is my impression that python is slow, at least it has a
> lengthy startup. It may still be suitable for certain tasks,
> however I have no idea which as I don't speak python. Mailman was
> run once per minute from cron on my old server. M
On Tue, 2003-11-25 at 15:06, Bernhard Kuemel wrote:
> It would probably be more efficient if some who are familiar with
> the mailman code fixed its "security flaws".
Just to be snitty and pedantic, I don't consider email address leaks in
Pipermail to be security flaws. Not that I don't conside
On Thu, 2003-11-27 at 12:17, Chuq Von Rospach wrote:
> that would be the answer, or throw it out (I'm not a huge fan of
> pipermail; it's only advantage to mailman is it's written in Python)
> and do something else. Or leave pipermail alone, and write a CGI that
> all archives exit through that
On Thu, 2003-11-27 at 12:08, Terri Oda wrote:
> > Better is to simply teach the archives not to distribute sensitive
> > information at all. And a lot easier to implement, actually.
>
> So, is anyone working on this *within* pipermail? I know there are great
> alternative archivers out there,
On Thu, 2003-11-27 at 10:49, Dietmar Maurer wrote:
> Hi all,
>
> we are looking for a solution to implement secure mailing lists. We need the
> following behaviour:
>
> 1.) A secure mailing list has an assiciated PGP Key.
> 2.) postings to the list are encrypted with the public key of the list.
On Thu, Nov 27, 2003 at 09:17:33AM -0800, Chuq Von Rospach wrote:
> if it can be made accessible, I have no problem with it. But I think
> it's solving the wrong problem, because the data is still accessible to
> a motivated person. you're not fixing the issue, simply raising the bar
> and hopin
On Thu, 27 Nov 2003 09:17:33 -0800
Chuq Von Rospach <[EMAIL PROTECTED]> wrote:
> On Nov 27, 2003, at 9:08 AM, Terri Oda wrote:
>> On Tue, Nov 25, 2003 at 11:07:39AM -0800, Chuq Von Rospach wrote:
> Remember challenge/response? When everyone thought it was the solution
> to all of our problems? To
On Nov 27, 2003, at 9:08 AM, Terri Oda wrote:
On Tue, Nov 25, 2003 at 11:07:39AM -0800, Chuq Von Rospach wrote:
Fails ADA and accessibility requirements badly. I'd argue against any
solution that fails such basic needs without any real way to fix it.
What about reverse turing tests that aren't gra
On Thu, 27 Nov 2003 12:08:24 -0500
Terri Oda <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 25, 2003 at 11:07:39AM -0800, Chuq Von Rospach wrote:
> I know there are great alternative archivers out there, but Mailman
> still winds up with a bad reputation if the default isn't very secure.
Disagreed.
>
On Thu, 27 Nov 2003 16:49:58 +0100
Dietmar Maurer <[EMAIL PROTECTED]> wrote:
> Hi all, we are looking for a solution to implement secure mailing
> lists. We need the following behaviour:
Architecturally it can be accomplished at either the MLM or MTA level
without enourmous difficulty. The prob
On Tue, Nov 25, 2003 at 11:07:39AM -0800, Chuq Von Rospach wrote:
> Fails ADA and accessibility requirements badly. I'd argue against any
> solution that fails such basic needs without any real way to fix it.
What about reverse turing tests that aren't graphics-based? It's easier to
beat "What
On Thu, 27 Nov 2003 10:46:27 -0500
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Thu, 2003-11-27 at 03:47, PieterB wrote:
> For the next version of Mailman, I'd prefer to see something more
> generic if possible.
+1
> That way a site could add SA, SB[1], or some other system. It may be
> too
Alle 16:46, giovedì 27 novembre 2003, Barry Warsaw ha scritto:
> For the next version of Mailman, I'd prefer to see something more
> generic if possible. That way a site could add SA, SB[1], or some other
> system. It may be too hard to do this since there are no standards
> here, but even then,
Hi all,
we are looking for a solution to implement secure mailing lists. We need the following
behaviour:
1.) A secure mailing list has an assiciated PGP Key.
2.) postings to the list are encrypted with the public key of the list.
3.) The list server decrypts the message, and then, for each list
Bernhard Kuemel wrote:
A million string interpolations and file accesses in 2.1 s - not bad.
Hmm, maybe the startup overhead of python is still significant
with 1,000,000 iterations so here are 10,000,000 timings:
[EMAIL PROTECTED]:~/src/benchmark$ time perl -e 'for
($i=1;$i<=1000;$i++) {pri
Richard Barrett wrote:
Maybe. However, I don't like python as on our old P60 server it burned
up so much CPU time (15 s/min).
It would be interesting to see you present convincing evidence that
Python runs slower than Perl which you seem happy to rely on.
That can be difficult as different progra
Richard Barrett wrote:
Since your answer is the only one and the problem does not appear to
be addressed sufficiently I wrote an example exploit program that
finds mailman lists and harvests their email addresses. After about
20 minutes it collected about 30.000 email addresses:
http://bks
Doug Selph wrote:
On Tuesday, Nov 25, 2003, at 11:46 US/Central, Bernhard Kuemel wrote:
If you think the problem is worth fixing please estimate how long it
will take and I will wait a reasonable time for a fix before I post
the problem and the exploit code to bugtraq. Otherwise I will post to
On Thu, 2003-11-27 at 03:47, PieterB wrote:
> It would be great if the MM 2.1.4 distribution will contain the
> files needed for spamassassin integration.
We can't really add this to 2.1 because it would be a new feature.
> I'm willing to help you with the SA-integration. I didn't hear
> Barry
On Wed, Nov 26, 2003 at 04:33:45PM -0400, Jeff Warnica wrote:
> First: If I was to submit a (compleate) set of patches that allow at
> least some per list configuration for SpamAssassin integration, would
> they be accepted?
I hope those patches will be accepted! Also see my patch mentioned
in ht
31 matches
Mail list logo
