Barry Warsaw writes:
Me too. Here's my discussion on the topic, including a concrete
proposal for Mailman 2.1.10 and 2.2/3.0. Feel free to comment on the
wiki on in this thread.
I'll try to post to the wiki later (I'm not a member yet and I'm
suffering mail delays---I expect I'll
Michael Thomas writes:
I'm afraid that there's not much consensus on how to deal with the
mailing list issue; the people who say resign are guessing as there
is little/no evidence that resigning is actually a viable strategy.
From the point of view of the mailing lists, resigning is
Barry Warsaw writes:
Part of me agrees that this is what you'd like to see, but my gut
tells me that this will never work in practice. First, no one but an
email geek will even understand the question, let alone know how to
answer it,
Agreed. It's a stalking horse for the BCP;
Barry Warsaw writes:
What should MM2.1 do now? Here's a proposal for 2.1.10: Add an
mm_cfg.py variable that controls whether DKIM headers are stripped or
not. I think Mark suggested that this should be a site-wide
variable, and I tend to agree.
I've expressed my reservations
Barry Warsaw writes:
Make sure no spam gets through your double opt-in list, and you're
golden, no?
Ideally yeah. But python.org does get reported occasionally since
while I think we do a pretty good job of blocking most spam, some
nasties gated from Usenet still get through.
Michael Thomas writes:
I'm not saying I think that resigning is a Bad Thing, I'm saying that it's
speculative whether it's a Good Thing. You seem to keep ignoring the
inherent attack involved with resigning:
Have you actually read my posts, or just enough to feel defensive?
I have
Michael Thomas writes:
Let's be clear that I'm advocating a dialog here,
In some sense, there's very little room for dialog, unless it involves
substantial amendments to DKIM. This is inherent in the design: the
whole message is signed. Preserve it nearly verbatim or break the
signature.
Joe Peterson writes:
With DKIM, according to my understanding, you are supposed to treat a
bad sig the same way you'd treat no sig.
I don't think the spec says that. It says:
A verifier SHOULD NOT treat a message that has one or more bad
signatures and no good signatures differently
Michael Thomas writes:
I'm afraid that intransigence from the mailing list community is
likely to really backfire. Mailing list traffic is an extremely
small percentage of traffic, and most admins are likely to just
ignore the collateral damage if it's too much a nuisance.
We know.
Michael Thomas writes:
What it seems to me is that maybe we should look close at that
behavior of when a list ought to take From: responsibility for a
message ala digests. When a list completely mangles a message, is
it really reasonable for it to keep acting as if it came from the
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW I agree that this is what we should hope for. Our data
BAW supporting the rewriting of Sender is many years out of date,
BAW so we need to gather more data. Who's brave enough to try
BAW it? :)
If this can be done by modifying
James == James Ralston [EMAIL PROTECTED] writes:
James The Sender header should be employed by the orignator of
James the message, and only the originator. Mailman is not the
James originator of a message sent to a list;
OK up to here.
James it is merely a relay agent.
That
Brad == Brad Knowles [EMAIL PROTECTED] writes:
At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote:
Whatever else we decide, I don't agree, or at least, it won't
help us. $3.6.6 says that Resent-* headers are to be added by
a user. It also says that these are purely informational
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW Ideally, we'd get rid of all that for 2.2 and deal only with
BAW Unicode internally.
The original encoded stuff should be squirreled away somewhere for
debugging and maybe spam detection, though.
BAW We may have to make
Brad == Brad Knowles [EMAIL PROTECTED] writes:
Brad Personally, I think we should default to US-ASCII in
Brad the log files, but I can see where some people might want to
Brad select a different encoding in mm_cfg.py.
I really think the log files should be UTF-8. The point is
Kevin == Kevin Kubasik [EMAIL PROTECTED] writes:
Kevin Or a way for one moderator to view all pending messages by
Kevin logging in once. Since it is not uncommon that one spammer
Kevin crawls the site and sends the same message to every list,
Kevin it can become a routine
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW I really /wanted/ to use TAL but it was way too unwieldy to
BAW develop.
+1 Unfortunately, TAL doesn't seem to scale _down_ to typical
volunteer-staffed open source.
--
School of Systems and Information Engineering
Mark == Mark Sapiro [EMAIL PROTECTED] writes:
Mark The problem I see is that while header_filter_rules are in
Mark the Spam filters section of the admin interface and enforced
Mark by a module named SpamDetect, they can actually be used in
Mark other ways to reject messages which
J == J C Lawrence J writes:
J Long time no talk. Whaddya think of adding message_id as a
J replaceable token for footers and the like? This would allow
J footers to be constructed which direct URL-reference their own
J post in an NNTP archive.
Or in a mailing list archive
Brad == Brad Knowles [EMAIL PROTECTED] writes:
Brad I can't speak for Barry or anyone else, but when I use
Brad Mailman to handle mailing lists for webmaster, postmaster,
Brad etc..., there is a 99% chance that any one particular
Brad message is spam, and I have to take a
Brad == Brad Knowles [EMAIL PROTECTED] writes:
3. Where possible, the information _and the controls_ for a single
entry should be on a single line. I think it's reasonable to
assume as a default that the moderator has at least a 1024px width
screen
Now there, I
R == R Bernstein [EMAIL PROTECTED] writes:
R Where I think something inside GNU Mailman could be a little
R better than a second list is that the integration could enforce
R that the email associated with person logging in to the webpage
R or sending moderation by email is also
Brad == Brad Knowles [EMAIL PROTECTED] writes:
Brad But then we're getting dangerously close to tools like
Brad Active Spam Killer or TMDA,
Technically, yes.
Brad which I am generally violently opposed to.
Brad Maybe those kinds of tools are appropriate for mailing
Tokio == Tokio Kikuchi [EMAIL PROTECTED] writes:
Tokio SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = True
Tokio May be we should set this default in Defaults.py.in in the
Tokio next release of 2.1.7. Thoughts?
I think that's a good idea. Very few users have any idea what the
file name
JC == JC Dill [EMAIL PROTECTED] writes:
JC The posts we are hoping to keep OFF of -dev and ON -users are
JC the posts by users who are having what they believe are
JC complicated use problems and they want advanced support
[...]
JC As long as the topic brought here is about
Max == Max Bowsher [EMAIL PROTECTED] writes:
Max My point in saying what I did was that 'the URL to the user
Max webpage' and 'the URL for the admin webpage' are not
Max independently settable entities. They are, in fact,
Max identical, just one has things like 'listinfo' or
Max == Max Bowsher [EMAIL PROTECTED] writes:
Max Is there any reason not to add web_page_url to the
Max configurable options in the admin GUI? Right below host_name
Max in the general category would be a good place.
Yes, please!
--
School of Systems and Information Engineering
John == John W Baxter [EMAIL PROTECTED] writes:
John Thought experiment: 1. Make a typo which cripples the URL
John such that you can't reach the admin web page.
I actually don't care what the admin URL(s) are. That's what
bookmarks are for, and my list admins can learn to use them,
Ian == Ian Eiloart [EMAIL PROTECTED] writes:
Ian I think Python regular expressions have enough in common with
Ian the PCRE (perl compatible regular expressions) library to be
Ian useful. For example, I think [EMAIL PROTECTED]@(.*\.)?sus(se)?\.ac\.uk$
Ian has the same meaning in
Brad == Brad Knowles [EMAIL PROTECTED] writes:
For access to the ACL database, we really need only to consider
two MTAs (at most): Exim and Postfix.
Brad You have to give the MTA direct access to the internal
Brad filters of Mailman in some sense.
To get all the way to
Ian == Ian Eiloart [EMAIL PROTECTED] writes:
Ian No, you've evidently completely misunderstood me. All I do
Ian want is for Mailman to use *exactly* the same mechanisms for
Ian sender ACLs that it does for rosters. If that's LDAP, that's
Ian fine. If it's SQL, that's fine. If
Brad == Brad Knowles [EMAIL PROTECTED] writes:
Brad Show me a single open data format that all MTAs
Brad understand. Hell, there aren't many file formats that they
Brad all understand.
C'mon, Brad, don't let the perfect be the enemy of all improvement.
For access to the ACL
Kevin == Kevin McCann [EMAIL PROTECTED] writes:
Kevin I guess I have to watch the words I choose. Erase the word
Kevin beg,
No. It's the right word for the behavior I've observed so far on the
MM lists. (I'm excluding your most recent reply to Brad, which
demonstrates (to me, anyway)
Kevin == Kevin McCann [EMAIL PROTECTED] writes:
Kevin Is this fair, Stephen? The word I was used to indicate
Kevin who had worked on the specs, not who would be involved in
Kevin implementing them. Why insinuate a personality trait here?
My point is that I know of two people who
Kevin == Kevin McCann [EMAIL PROTECTED] writes:
[about project management]
Kevin - The Mailman project is not as open as it could be. There
Kevin is too much control over who can contribute code, how they
Kevin can do it, when they can do it. I understand wanting to
Kevin
Tokio == Tokio Kikuchi [EMAIL PROTECTED] writes:
Tokio - Is the terminology 'sibling' appropriate?
I hesistate to give it a +1 because I know I think differently from
most people, but FWIW I *did* guess what it does from that name.
--
School of Systems and Information Engineering
Brad == Brad Knowles [EMAIL PROTECTED] writes:
Brad The problem is that a majority of the people who run
Brad python.org are also heavily involved in Debian, so we're
Brad pretty much guaranteed to be shackled by whatever the Debian
Brad people want to do.
Maybe so, but I
Nadim == Nadim Shaikli [EMAIL PROTECTED] writes:
Nadim I've noticed of late that emails sent by yahoo users that
Nadim get relayed by mailman end-up without the domainkey header
Nadim entry and thus in various yahoo users' bulk (ie. spam)
Nadim folder. Is there anything that can
Joseph == Joseph Tate [EMAIL PROTECTED] writes:
Joseph Finally, I'd like some discussion of licensing. I think
Joseph that the xmlrpc.py file itself should be LGPL just so that
Joseph there is no ambiguity whatsoever about using XML-RPC calls
Joseph from a non-GPL application.
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW On Fri, 2005-07-22 at 02:08, Stephen J. Turnbull wrote:
Unfortunately, linking is not a necessary condition for a
program to be a derivative work, merely a sufficient one. I
would suspect that Richard Stallman and Eben Moglen
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW On Thu, 2005-05-12 at 19:48, Chuq Von Rospach wrote:
Does archiving need to be integrated into mailman in the first
place? As opposed to, say, a place to specifiy the URL of the
archives for display?
BAW The key is that
Bob == Bob Puff [EMAIL PROTECTED] writes:
Bob Personally, I'd much rather see the HT/Dig patch implemented
Bob before this one. That is IMHO more useful to the average
Bob mailman admin than this.
Jeff's patch is so simple you could prove its correctness
mathematically. The
Brad == Brad Knowles [EMAIL PROTECTED] writes:
Brad At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote:
It's not a good idea to put the burden of proof on them, when
either the list-owner can be more selective about membership,
or they can use X-No-Archive.
Brad
Brad == Brad Knowles [EMAIL PROTECTED] writes:
Brad Lars was nice enough to comply with our request to
Brad remove our lists from gmane, but these kinds of operations
Brad should not be done without a positive and explicit approval
Brad from the listmaster.
Any subscriber
JC == JC Dill [EMAIL PROTECTED] writes:
JC I personally don't see it as being a significant endorsement.
JC AIUI, it's a patch that allows 2 software programs to work
JC well together.
My understanding is that the programs already work well together; you
just type [EMAIL PROTECTED]
Alan == Alan Batie [EMAIL PROTECTED] writes:
Alan Tokio Kikuchi wrote:
- Most of the installation instructions have been moved to a
latex document. See admin/www/mailman-install/index.html for
details.
Alan This is *not* a positive move. Installation instructions
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW On Tue, 2004-11-30 at 20:07, Tokio Kikuchi wrote:
May be we can go forward to requirement of Python 2.4 because
CJK codecs are integreted there.
BAW I have no problems requiring Python 2.4 for Mailman 2.2,
BAW although I
Steven == Steven Kuck [EMAIL PROTECTED] writes:
At 3:31 AM -0500 2004-11-20, Steven Kuck wrote:
Since all of these messages are, in fact, being sent by my
server I think it quite reasonable to change the Date to
reflect the time that it was processed and changed by the
Brad == Brad Knowles [EMAIL PROTECTED] writes:
I don't think I'm being pessimistic here. I think I'm being
realistic. There are no deterministic ways to figure out
precisely which message is being replied to and which other
messages are being referenced, unless
Brad == Brad Knowles [EMAIL PROTECTED] writes:
Brad You could spend a trillion dollars on this problem and
Brad not find a solution. The entire computer industry has been
Brad working on AI since the early 1960s, and they haven't solve
Brad it yet, and don't appear to be
Tokio == Tokio Kikuchi [EMAIL PROTECTED] writes:
Tokio I think I should commit one of my unpublishd patch on
Tokio SourceForge CVS.
[...]
Tokio With this patch, site manager can set
Tokio SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True in
Tokio mm_cfg.py to use attachment
Michael == Michael Heydekamp [EMAIL PROTECTED] writes:
Michael I'm aware of all of these problems but that still doesn't
Michael explain ...
Michael a) why Mailman recodes the UTF-8 body to base64 rather
Michael than qp (which would be the recommended and much better
Michael
Daniel == Daniel Buchmann [EMAIL PROTECTED] writes:
Daniel Here's a summary of Python versions on other popular
Daniel distro's:
[Linux reports elided]
On Mac OS X 10.3 (aka Panther), we have
Apple - 2.3
IIRC Mac OS X 10.2 (aka Jaguar) was Python 2.1. On the third-party
somuchfun == somuchfun [EMAIL PROTECTED] writes:
somuchfun I am literally shocked to see that you think everyone
somuchfun who does not agree with you is a Spamer!
That's not what he said. He said he can't think of a good reason why
a non-spammer would want to do this, while there are
Chuq == Chuq Von Rospach [EMAIL PROTECTED] writes:
Chuq my current thought on that is:
Chuq http://www.plaidworks.com/chuqui/blog/001447.html
My now-ancient thought on this is
http://turnbull.sk.tsukuba.ac.jp/Tools/Attitude/
Warning, it swears like a bounce.
Chuq so my
BAW == Barry A Warsaw [EMAIL PROTECTED] writes:
BAW but instead will get split like
X-Foobar-Spoink-Defrobnit: wasnipoop; giraffes=very-long-necked-animals; spo
oge=yummy; hippos=gargantuan; marshmallows=gooey
If by split you mean RFC 2822 2.2.3 header folding, you can't split
spooge
BAW == Barry A Warsaw [EMAIL PROTECTED] writes:
BAW Currently the SourceForge bug and patch trackers for the
BAW Mailman project are set to send messages to
BAW [EMAIL PROTECTED]
BAW I'm wondering if it would be useful to redirect those
BAW messages to mailman-developers.
Ben == Ben Gertzfield [EMAIL PROTECTED] writes:
Ben On Saturday, April 13, 2002, at 02:59 , Stephen J. Turnbull
Ben wrote:
Ben Either we need represent the whole thing as one or more
Ben encoded-words, or we need to be super anal about whitespace
Ben between encoded-words
Ben == Ben Gertzfield [EMAIL PROTECTED] writes:
Ben I think the email.Header package I wrote is doing the wrong
Ben thing here.
Yup.
Ben Either we need represent the whole thing as one or more
Ben encoded-words, or we need to be super anal about whitespace
Ben between
Jay == Jay R Ashworth [EMAIL PROTECTED] writes re HTML email:
Jay which is inherent, I think, in the (lack of) design thereof.
What lack of design? It's a near-perfect implementation of form over
substance.
--
Institute of Policy and Planning Sciences
Ben == Ben Gertzfield [EMAIL PROTECTED] writes:
Ben Mein Gott. If people start sending mail in UTF-16.. wow.
Outhouse Abcess. wink, wink, nudge, nudge Say no more, eh?
And yes, I have gotten such. (A _very_ broken beta of Outhouse for
Lose2k beta was responsible: the HTML tags were in
Ben == Ben Gertzfield [EMAIL PROTECTED] writes:
Ben This would violate RFC 1522:
That's right. People with broken mailers have broken mailers. Make
sure that things are robust for those with decent software, and then
do what we can for the former poor souls.
Anyway, even my boss---who
BAW == Barry A Warsaw [EMAIL PROTECTED] writes:
BAW I /think/ I've caught up on this thread,
Like JRA I think your synopsis is accurate, with respect to the issues
that can be addressed by code.
BAW I claim that the guessability [of list-related addresses] is
BAW a feature, btw.
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,
Chuq == Chuq Von Rospach [EMAIL PROTECTED] writes:
Chuq You know, now that I think of it, there's another approach:
Chuq you don't get the admin's email address until you
Chuq authenticate. Then you get it. [...]
Chuq Thoughts?
You've just reinvented TMDA, basically, except
I repeat myself, but only Chuq seems to have noticed the other post.
John == John Morton [EMAIL PROTECTED] writes:
John This depends on just how temporary your 'solution' turns out
John to be, and it's level of complexity and usability. I don't
John think anyone has really advocate
Damien == Damien Morton [EMAIL PROTECTED] writes:
Damien So obfuscation is imperfect, and the more effective it is,
Damien the more value there is in cracking it.
That's true, but that's not what I said.
What I said is it is weak enough that a small amount of effort brings
some payoff
Chuq == Chuq Von Rospach [EMAIL PROTECTED] writes:
Chuq On 2/20/02 1:37 PM, Damien Morton
Chuq [EMAIL PROTECTED] wrote:
As far as I can see thay are using url/cgi encoding in the
email address. This is trivial to circumvent, as is using html
entities, or any other
BAW == Barry A Warsaw [EMAIL PROTECTED] writes:
BAW evil laugh=manical
BAW Mailman shall rule THE WORLD!
BAW /evil
Take a number, man. (See .sig.)
--
University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences
901 - 969 of 969 matches
Mail list logo
