On Fri, 18 Jun 2004 20:38:42 -0300
Christian Robottom Reis <kiko(a)async.com.br> wrote:
> Just a heads-up for bug 930819, which has a patch (two now) that adds
> onload form focus to the password entry in admlogin.html, a usability
> improvement for people using graphical browsers and maintaining many
> lists.
+1
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
On Wed, 30 Jun 2004 09:04:14 -0700
somuchfun <somuchfun(a)atlantismail.com> wrote:
> The issue is not whether it was obvious or not, the issue is that this
> new feature cannot even be turned off, just changed to a different
> format. Since there are many configurations out there that might not
> work with VERP I find introducing a feature that is on by default and
> that cannot be turned off causing more harm than doing good.
Without disagreeing with your point:
At some point Mailman ends up in the position of pushing technical
standard adoption (such as the RFC 2369 List-* headers). No matter
when the adoption decision is made someone will be unhappy.
Plus addressing is not even close to new. I'm aware of no production
MTAs that don't support plus-addressing. At what point should Mailman
simply assume technical capability on the part of installation sites?
Mailman already currently assumes a number of non-default things about
the execution space, why not plus-addressing as well?
When is the right time?
Remember: You don't have to upgrade.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
On Thu, 24 Jun 2004 03:44:32 -0700
somuchfun <somuchfun(a)atlantismail.com> wrote:
> This new VERP probe is ridiculous. One of my customer on a cpanel
> system had thousands of unsubscribes because of it. Why? Cpanel does
> not support in its current default exim setting VERP and there was no
> need for it because it is not on by default in mailman. Now out of the
> blue it is used even though VERP is turned off in mm_mfg.py And since
> this mailman VERP probe is unforgiving it unsubscribes right away!
> Not a good thing at all and the complaints from customers are coming
> in big time........
So you deployed a new software into production without first making
there were no negative impacts? Nice QC there.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
Does anyone know how to make a text field in Jira read only or how to
just display the information in the field.
Bev
Bev Scott
Web Database
Portland Public Schools
503-916-2000 4966
bscott(a)pps.k12.or.us
I'm in the process of transferring lists to a new server. The old
server runs mailman 2.1.4, and the new one runs 2.1.5. I copied over
the lists directory and the archives directory, and I ran update -f to
update the lists. It seems to be working except for the fact that now
the lists don't show up on the main listinfo page. Before they were
listed publicly. How can I get this back? And is there anything else
I'm missing in this process of moving lists?
Thanks,
Joel Ebel
MM 2.1.5
After complaints from some list members about the text of their messages
going missing when viewed in the archives I've noticed some slightly
undesirable behaviour in the scrubber module.
The problem concerns people who regularly send multipart/alternative
messages containing text/plain and text/html parts. The scrubbing policy
for the site is correctly implemented for these people until the user
decides to send an attachment. At that point the message becomes a
multipart/mixed message containing two a multipart/alternative and some
other attachment, typically application/msword or some such.
The scrubber uses the "walk" method of an email message to find and scrub
those hard-to-shift HTML stains but when the archiver page is generated in
the second pass the scrubber uses the get_payload method instead. As a
result, the scrubber never descends into the nested multipart/alternative
part and doesn't display either the text of the message or a link to the
HTML attachment (your results will vary depending on your site policy for
the archiver).
Is this a bug or is there a real reason why get_payload is used for the
second stage of the scrubber process?
Steve Lay
Jun 24 15:49:39 2004 (353) lost data files for filebase:
1088100914.7161551+9a9200d2cba7be877a02453e1f812069b0c78761
<rinse and repeat about once a second>
Mailman 2.1.2 (I'll upgrade if you INSIST...)
Python 2.2
SunOS eh.net 5.7 Generic_106541-24 sun4u sparc SUNW,Ultra-5_10
I've been getting this line thrown in my error logfile frequently.
Additionally, mailman has about 1200 files open when the (aging) computer
locks up after taking quite a bit of abuse (it tends to end up with the
CPU at 100% iowait, out of swap, with more processes running than is
healthy. (The machine only has 256 megabytes of RAM-- and the replacement
server was initially due to arrive over a month ago, but Hewlett-Packard
has delayed that date to about a month from now).
I've seen this question asked before somewhere in the archives (
http://www.mail-archive.com/mailman-developers@python.org/msg06528.html )
but the (very limited) answer does not seem to have helped.
So the problem I described last January and again mentioned last September is
still happening to me, and now to a lot more people. It will only become more
and more prevalent as viruses become more common and sites that filter them
become more common.
Perhaps I should restate the problem more simply. Mailman is committing the
basic sin of network security -- receiving data from the network and trusting
it for purposes other than as opaque data.
It is using messages posted to the list -- the content and format of which it
does not control -- to detect bouncing email addresses. Because of this it
cannot tell if the bounces it's receiving are caused by a broken email address
or caused by some particularity of the posted message.
Virus scans are only one type of bounce that could cause someone to be
unsubscribed spuriously. For example, most mail servers have a maximum message
size for example. Consider the security implications: all I have to do to mass
unsubscribe many people--even everyone--on a list is send a message over 50k.
Everyone using old versions of sendmail will be unsubscribed. A larger message
will unsubscribe anyone using most modern MTAs. Nor do the tests that require
multiple bounces protect anything; I just have to send my attack a few times
quickly.
Really Mailman should simply not trust outside data for any purpose. It should
treat the bounces received from mailing list messages purely as hints. It
should then send its *own* message with content not subject to any control
from outside to the user. Only if that known inoffensive message bounces
should it consider removing the user.
This is really a DOS security issue, though the worst case attack is
unsubscribing many users of a list. That it gets triggered normally even when
not specifically under attack only makes the problem apparent.
--
greg
On Thu, 24 Jun 2004 00:46:09 +0200
Brad Knowles <brad.knowles(a)skynet.be> wrote:
> At 10:22 AM -0400 2004-06-19, J C Lawrence wrote:
>> Does 2.1.5 formally require plus addressing support in the MTA?
> That's only required if you let the MTA generate the VERP.
Not quite. It minimally requires plus addressing to be enabled in the
MTA (assuming it supports it).
>> I thought that was still optional if you didn't use any of the
>> VERPish supports.
> If the client generates the VERP, the MTA should pass that through
> unchanged. At that point, a string-up-to-@ should be a
> string-up-to-@.
Right, modulo the plus address extension removal.
> I've used this on installations I've done, and I have not done
> anything special with the MTAs to configure them for VERP
> support. What they provided out-of-the-box has worked just fine.
I'm not familiar with the various common MTAs current OTB configuration.
When last I checked (year+ ago) most didn't enable plus addressing
support by default.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.