Mailman 3 October 2000 - Mailman-Developers

Mailman-Bug with faked spam headers and some suggestions new features
by Steffen Bardolatzi 11 Oct '00

11 Oct '00

This looks like a nasty bug ... We are running Mailman for some time now - one of the liste is a "half-open" one with these settings: - everyone can post - bccs to the list are not permitted (to avoid spams, works fine) - some alias-names for some users who regulary post to a different adress but bcc to our's Recently a spam message with a visible to-entry in the mail header arrived here: "To: <>" in the fields displayed by mail clients. This caused to log Mailman Beta 6 the following files into the error- logfile: Oct 08 23:53:01 2000 (25258) Delivery exception: read-only character buffer, None Oct 08 23:53:01 2000 (25258) Traceback (innermost last): File "/var/mailman/Mailman/Handlers/HandlerAPI.py", line 82, in do_pipeline func(mlist, msg, msgdata) File "/var/mailman/Mailman/Handlers/Hold.py", line 173, in process if mlist.require_explicit_destination and \ File "/var/mailman/Mailman/MailList.py", line 1208, in HasExplicitDest addr = string.lower(addr) TypeError: read-only character buffer, None ... these lines were repeated each *2* minutes for more than 10 hours (until I deleted the db-, and msg-file in the qfiles directory). The original msg-file time was exactly the one of the first log in the log file. In this *first* log I could read something like "implicit header..." followed by the endlessly repeated actual error-log above. ------------------------------- In addition to this here are some more minior bugs: - In case some e-mails are sent with qp-7bit-code the archiver does *not* covert them back into the acutal 8 bit characters - which makes it more diffucult to read the postings in the archive unless you are get used to qp-coding. As for 8 bit characters it works fine. Some of the affected mail clients are Pegasus und Outlook Express (according to some header analyses on an unregular bases). E-Mails are send just fine with no problems. - In case some people send M$-attachments the archive does not interpret this mime code and displays if just as if it was plain text. A nice *new* feature was if there was displayed a link for non-text-files like: download this file. - It would be fine if the archive would *not* display both the text and html code (in source code) if some people send a message with html *and* txt - the default might be *only* to render the html part readable (as e.g. done my pine). In general it would be fine if the archive was mime-aware ... there are too many users out there who have not yet learnt to send e-mails in plain text. - In case there are packet losses and timeouts during processing some admin-(mail)-requests Mailman does recognize the changes but does endlessly attempt to load the updated admin-requests site. ------------------------------------------- - sugestion for a new feature: I was told to disable the unsubscribe-funktion for a special list: I edited the list option's site *and* disabled the request e-mail adress (else I had to filter out unsubscribe in the subject and body with procmail or so). So far this works fine *but* has been some work. Therefore a switch like: "unsubscribe yes no" would be a good idea - maybe on a per-list bases in the mydefauls.py-file. Thanks in advance and thaks for such a great mailing list manager! PS.: I hope it's ok if I send it to mailman-users and mailman-developers and sorry about the length. Anyway Mailman seems to get better with each Beta version.

1 0

software
by Kleniksky Artiom 10 Oct '00

10 Oct '00

Dear sirs, My name is Artiom Kleniksky, i am private businessman and work in sphere of telecommunications in Belarus. Presently I revise the direction of its activity and begin to work of software development! On given moment I have the big interest in reception of order on software production, any level to difficulties. At reception of order for 5 days I am ready to give answer about possibility of its realization. I am ready to guarantee the quality and periods of performances order. The Payment expect the transfer of cheque on my name on fact of performance of order. For first time a downpayment for performance work is not required. I certain that we with can find the general interests and shall cooperation to future! I wait any offers from you! My e-mail:minsk_mobile@mail.ru GSM: +375-296-500-950 With best regards Artiom Kleniksky

1 0

Bug in CookHeaders.py
by Jerzy Hodor 08 Oct '00

08 Oct '00

Hello, I have just discovered a bug in Mailman 2.0beta6. When you set up a list to post replies to list, and user receives confirmation note about subsciption, the CookHandlers module trashes content of 'Reply-To' field. Accordingly to comments in this code there is wrong written condition in it.You should change it from: if not fasttrack or msg.get('reply-to'): to: if not fasttrack or not msg.get('reply-to'): or even to cleaner form: if not (fasttrack and msg.get('reply-to')): Here is diff -uNr of CookHeaders.py.orig CookHeaders.py <---------cut here --- CookHeaders.py.orig Sun Oct 8 12:53:40 2000 +++ CookHeaders.py Sun Oct 8 12:54:30 2000 @@ -79,7 +79,7 @@ # or if there is already a reply-to set. If the user has set # one we assume they have a good reason for it, and we don't # second guess them. - if not fasttrack or msg.get('reply-to'): + if not fasttrack or not msg.get('reply-to'): # Set Reply-To: header to point back to this list if mlist.reply_goes_to_list == 1: msg['Reply-To'] = mlist.GetListEmail() <---------cut here Hope this helps developing your great program! Sincerely yours, -- Jerzy Hodor PS. Yes, I have posted this bug and patch on sourceforge :-)

1 0

2.0b6 & approval page forward function
by Ricardo Kustner 07 Oct '00

07 Oct '00

Hi, I noticed some odd behaviour of the forward function on the held-for-approval page. It used to work in earlier betas, but it doesn't seem to work the same in 2.0b6. When I approve a message and use the forward option, the message gets send only once. There's no Subject prefix in the message I receive, so I _think_ it doesn't get delivered to the rest of the list (which is probably true cause the entry in logs/smtp talks about 1 recips). But the msg['Send-To'] header is nowhere to be found in the message. Unfortunately, it looks like the message doesn't get delivered to the list, even though i "approved" it too... but I have to test that some more to me 100% positive it doesn't get delivered. I'll look into it some more tonight, and if I have more details I'll submit a bugreport on sourceforge... Ricardo.l -- http://rixhq.nu "You think that's air you're breathing?" -- Morpheus

1 1

Virtual Host handling in listinfo.py
by Richard Barrett 06 Oct '00

06 Oct '00

In what follows I am referring to code in the file Mailman/Cgi/listinfo.py in the 2.0beta6 release of Mailman. I'm working with Apache/1.3.12 (Unix) which may influence your judgement about my arguments. Sorry if what follows is too long but I found it useful to fully analyse my own thinking on the topic. Red face for me if the issue is well known to you all. The code I'm concerned with is in the function FormatListinfoOverview. It deals with the situation when mm_cfg.VIRTUAL_HOST_OVERVIEW is true and computation is done to detemine which advertised mail lists should be returned when the URI /mailman/listinfo/ is being responded to. The relevant bits of the code are as follows: def FormatListinfoOverview(error=None): ... <snip> ... http_host = os.environ.get('HTTP_HOST', os.environ.get('SERVER_NAME')) port = os.environ.get('SERVER_PORT') # strip off the port if there is one if port and http_host[-len(port)-1:] == ':'+port: http_host = http_host[:-len(port)-1] if mm_cfg.VIRTUAL_HOST_OVERVIEW and http_host: host_name = http_host else: host_name = mm_cfg.DEFAULT_HOST_NAME ... <snip> ... for n in names: if mlist.advertised: if mm_cfg.VIRTUAL_HOST_OVERVIEW and \ http_host and \ string.find(http_host, mlist.web_page_url) == -1 and \ string.find(mlist.web_page_url, http_host) == -1: # List is for different identity of this host - skip it. continue else: advertised.append(mlist) ... <snip> There is a flaw in this code in the way that it strips the port number from the http_host variable but I'll come on to that below. As best I can judge the purpose of considering the value of the environment variable HTTP_HOST (if available) instead of just using the SERVER_NAME value is to try and deduce a virtual host's server name in cirumstances when the web server has not. For instance: 1. Typically VirtualHost directives in httpd.conf will have been defined using FQDN, for example: NameVirtualHost 192.168.1.1 <VirtualHost bert.my.co.uk> ServerName bert.my.co.uk </VirutalHost> <VirtualHost fred.my.co.uk> ServerName fred.my.co.uk </VirutalHost> 2. The virtual hosts will have associated ServerName directives whose values are used to set SERVER_NAME. 3. If a user on the local network uses a URL which does not fully quality the servers domain name, e.g. http://fred/mailman/listinfo/, then the VirtualHost directive is not correlated by the web server and the SERVER_NAME will not be set to fred.my.co.uk but to some other value depending on type and order of the VirtualHost directives in httpd.conf, bert.my.co.uk in this example. 4. In these circumstances, the cunning code above will ignore the SERVER_NAME value and match the fred value in HTTP_HOST. I do not think this trick in the FormatListinfoOverview function is the right way to overcome this problem. If you want to match both partial and fully qualified domain names to a virtual host then two VirtualHost directives should be used in httpd.conf, for example: NameVirtualHost 192.168.1.1 <VirtualHost bert.my.co.uk> ServerName bert.my.co.uk </VirutalHost> <VirtualHost fred.my.co.uk> ServerName fred.my.co.uk </VirutalHost> <VirtualHost fred> ServerName fred.my.co.uk </VirutalHost> By doing this both web server and listinfo.py reach the same conclusion by the same route. I am saying that, in principle, the problem, which is generic to the way the web server is operating, should be solved by setting up the correct virtual host definitions in httpd.conf not by second guessing the virtual host setup in listinfo.py. listinfo.py should only consider the value of SERVER_NAME and not even look at HTTP_HOST. My proposed changes to the FormatListinfoOverview function are: cut here-vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv diff -r -c2 mailman-2.0beta6.stock/Mailman/Cgi/listinfo.py mailman-2.0beta6.listinfo1/Mailman/Cgi/listinfo.py *** mailman-2.0beta6.stock/Mailman/Cgi/listinfo.py Wed Aug 2 00:10:41 2000 --- mailman-2.0beta6.listinfo1/Mailman/Cgi/listinfo.py Fri Oct 6 14:22:44 2000 *************** *** 59,73 **** "Present a general welcome and itemize the (public) lists for this host." ! # XXX We need a portable way to determine the host by which we are being ! # visited! An absolute URL would do... ! http_host = os.environ.get('HTTP_HOST', os.environ.get('SERVER_NAME')) ! port = os.environ.get('SERVER_PORT') ! # strip off the port if there is one ! if port and http_host[-len(port)-1:] == ':'+port: ! http_host = http_host[:-len(port)-1] ! if mm_cfg.VIRTUAL_HOST_OVERVIEW and http_host: ! host_name = http_host ! else: ! host_name = mm_cfg.DEFAULT_HOST_NAME doc = Document() --- 59,63 ---- "Present a general welcome and itemize the (public) lists for this host." ! http_host = host_name = os.environ.get('SERVER_NAME') doc = Document() cut here-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [Even if you do not agree with my first conclusion, please read on.] Which brings me on to the problem that started me looking at this whole issue; what happens when SSH's port forwarding is used to make the browser/web connection? For example: 1. I'm dialling in to my favorite ISP from home using my laptop. In order to then connect to our internal-access-only Mailman web server through our corporate firewall, I have to use SSH's port forwarding. 2. I set up port forwarding so that any connection to local port 8081 on my laptop is forwarded to fred.my.co.uk:80 by the firewall machine. 3. I give my browser the URL http://localhost:8081/mailman/listinfo/. 4. The HTTP request is forwarded satisfactorily to fred.my.co.uk:80 with the URI being /mailman/listinfo/. 5. Because mm_cfg.VIRTUAL_HOST_OVERVIEW is true, listinfo.py proceeds to tell me there are no advertised mail lists on host localhost:8081. Well, I knew that. This is because of two flaws in the FormatListinfoOverview function: 1. In trying to remove the port number from the end of the string value of HTTP_HOST, the code assumes that the length of the port number is equal to the length of the SERVER_PORT environment variable's value. In the case of my example this is assumption is wrong: the port number at the end of HTTP_HOST is 4 characters ('8081') and the SERVER_PORT is 2 characters long ('80'). 2. Even with this first flaw corrected, the code still fails to recognise the circumstances because it is analysing HTTP_HOST and extracting the value 'localhost'. But the ip number of this value does not even match the SERVER_ADDR environment variable's value, which is a dead giveaway. This problem disappears if virtual host definition in httpd.conf is used instead of trickery involving HTTP_HOST in listinfo.py. So also does a similar problem which occurs if the explicit ip number of the server is used in the URL given to the browser, instead of the server's domain name, assuming no ip-based virtual host has been defined in httpd.conf to map the ip number to an acceptable ServerName. OK, so you do not agree with my contention that listinfo.py should not consider HTTP_HOST because it might break a bunch of existing Mailman installations. In that case, the following changes to the FormatListinfoOverview function avoid my problems. The position here is that if: either - The ip number of the HTTP_HOST doesn't match the SERVER_ADDR. or - The URL contains the server's ip number rather than its name. then the code behaves as if the browser didn't supply an HTTP Host header: cut here-vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv diff -r -c2 mailman-2.0beta6.stock/Mailman/Cgi/listinfo.py mailman-2.0beta6.listinfo2/Mailman/Cgi/listinfo.py *** mailman-2.0beta6.stock/Mailman/Cgi/listinfo.py Wed Aug 2 00:10:41 2000 --- mailman-2.0beta6.listinfo2/Mailman/Cgi/listinfo.py Fri Oct 6 15:06:31 2000 *************** *** 22,25 **** --- 22,26 ---- import os import string + import socket from Mailman import mm_cfg *************** *** 62,72 **** # visited! An absolute URL would do... http_host = os.environ.get('HTTP_HOST', os.environ.get('SERVER_NAME')) - port = os.environ.get('SERVER_PORT') # strip off the port if there is one ! if port and http_host[-len(port)-1:] == ':'+port: ! http_host = http_host[:-len(port)-1] ! if mm_cfg.VIRTUAL_HOST_OVERVIEW and http_host: host_name = http_host else: host_name = mm_cfg.DEFAULT_HOST_NAME --- 63,77 ---- # visited! An absolute URL would do... http_host = os.environ.get('HTTP_HOST', os.environ.get('SERVER_NAME')) # strip off the port if there is one ! if http_host: ! http_host = string.split(http_host, ':')[0] ! host_ip = socket.gethostbyname(http_host) ! server_ip = os.environ.get('SERVER_ADDR') ! if mm_cfg.VIRTUAL_HOST_OVERVIEW and http_host and \ ! host_ip == server_ip and \ ! host_ip != http_host: host_name = http_host else: + http_host = None host_name = mm_cfg.DEFAULT_HOST_NAME cut here-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have yet to post either of these above patches to sourceforge. I would appreciate a sanity check on my thinking and any rebuttal of my arguments or constructive comments. RSVP ------------------------------------------------------------------ Richard Barrett, PostPoint 30, e-mail:r.barrett@ftel.co.uk Fujitsu Telecommunications Europe Ltd, tel: (44) 121 717 6337 Solihull Parkway, Birmingham Business Park, B37 7YU, England "Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well armed lamb contesting the vote." Benjamin Franklin, 1759 ------------------------------------------------------------------

1 0

"download the full raw archive"
by Mentor Cana 05 Oct '00

05 Oct '00

Doesn't this link run contrary to the "obscure_addresses" Option? Even if I have the obscure_addresses Option set to YES, the e-mail addresses of public archives can be still harvested by various robots out there. later, Mentor

4 3

List-* header suggestion
by John A. Martin 05 Oct '00

05 Oct '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Would the long List-* header fields be more attractive and easier to read if they were folded something like the following? List-Subscribe: <http://www.python.org/mailman/listinfo/mailman-developers>, <mailto:mailman-developers-request@python.org?subject=subscribe> List-Unsubscribe: <http://www.python.org/mailman/listinfo/mailman-developers>, <mailto:mailman-developers-request@python.org?subject=unsubscribe> Perhaps folding after the comma would be OK unless the whole field is not greater than, say, 78 characters? jam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: OpenPGP encrypted mail preferred. See <http://www.gnupg.org/> iEYEARECAAYFAjnUnu8ACgkQUEvv1b/iXy9sBQCdEyGhXrxIs/9Vkpcc31wOPn7e iE8AoJPTJaw6bTSBHD1+TU5KNZVcs/ij =jNfW -----END PGP SIGNATURE-----

5 6

another weird mailman problem.
by Chuq Von Rospach 05 Oct '00

05 Oct '00

This just showed up in my logs... --- Sep 26 13:07:01 2000 (6974) Bhawks-l: lvymay(a)worldnet.fr - exceeded limits Sep 26 13:07:01 2000 (6974) Bhawks-l: disabled lvymay(a)worldnet.fr Sep 26 13:07:01 2000 (6974) Bouncer exception: body Sep 26 13:07:01 2000 (6974) Traceback (innermost last): File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 65, in ScanMessages mlist.RegisterBounce(addr, msg) File "/home/mailman/Mailman/Bouncer.py", line 141, in RegisterBounce self.HandleBouncingAddress(addr, msg) File "/home/mailman/Mailman/Bouncer.py", line 236, in HandleBouncingAddress text = text + \ AttributeError: body ---- I don't remember seeing this one before. -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com) And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

3 2

Re: [Mailman-Developers] broken CVS!
by Dan Mick 04 Oct '00

04 Oct '00

> >>>>> "CVR" == Chuq Von Rospach <chuqui(a)plaidworks.com> writes: > > CVR> I just updated to the current CVS, and it's broken: > > CVR> Traceback (innermost last): > CVR> File "/home/mailman/cron/qrunner", line 85, in ? from > CVR> Mailman import MailList File > CVR> "/home/mailman/Mailman/MailList.py", line 45, in ? from > CVR> Mailman.Archiver import Archiver File > CVR> "/home/mailman/Mailman/Archiver/__init__.py", line 17, in ? > CVR> from Archiver import * File > CVR> "/home/mailman/Mailman/Archiver/Archiver.py", line 33, in ? > CVR> from Mailman import Mailbox File > CVR> "/home/mailman/Mailman/Mailbox.py", line 43 <<<<<<< > CVR> Mailbox.py ^ > CVR> SyntaxError: invalid syntax > > When you updated, did you see a file that got checked out with a `C' > status letter? That means that something in your local version > conflicts with some changes in the master copy, and CVS can't resolve > it. You have to resolve the conflicts manually. Yeah, I hate that CVS is so silent about that. I've taken to doing "find . -type f | xargs grep '<<<<<'" every time I do "cvs update" (in a script). The stuff it leaves behind is *clearly* not usable, so I think there should be a big huge warning when it happens, and even an "invoke $EDITOR on the manual-merge-needy". But that's me.

4 3

broken CVS!
by Chuq Von Rospach 04 Oct '00

04 Oct '00

I just updated to the current CVS, and it's broken: Traceback (innermost last): File "/home/mailman/cron/qrunner", line 85, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 45, in ? from Mailman.Archiver import Archiver File "/home/mailman/Mailman/Archiver/__init__.py", line 17, in ? from Archiver import * File "/home/mailman/Mailman/Archiver/Archiver.py", line 33, in ? from Mailman import Mailbox File "/home/mailman/Mailman/Mailbox.py", line 43 <<<<<<< Mailbox.py ^ SyntaxError: invalid syntax -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com) You seem a decent fellow. I hate to die.

2 3