Menu
▾
▴
tmda-workers — TMDA Development
You can subscribe to this list here.
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(4) |
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(5) |
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Lukasz K. <sp...@on...> - 2017-12-26 10:12:15
|
Dear All, Is project still alive? The web site is dead for about 1-2 months, displaying in main page: > Traceback (most recent call last): > File "../moin/lib/python2.4/site-packages/MoinMoin/request.py", line 1207, in run > handler(self.page.page_name, self) > (...) I tried to contact developers individually, but no response. If you need any help in maintanining this project, please let me know (I am luqqe on sf and I have two own project on sf). I think the idea is too valuable to abandon it now. Greetings, Lukasz -- (www.komsta.net) |
|
From: Michael A. <mi...@ze...> - 2013-08-01 06:55:55
|
Hi folks,
After upgrading my Gentoo/Linux box, tmda-pending started throwing
"ValueError: too many values to unpack". I don't know what change
brought it on (my Python version is still at 2.7.3). Anyway, here's
the patch that fixed it for me:
--- /home/mike/tmp/tmda-1.1.12/TMDA/Pending.py 2007-01-17 16:49:44.000000000 -0500
+++ /usr/lib64/python2.7/site-packages/TMDA/Pending.py 2013-08-01 01:44:50.000000000 -0400
@@ -371,7 +375,7 @@
if Defaults.PENDING_RELEASE_APPEND:
Util.append_to_file(self.append_address,
Defaults.PENDING_RELEASE_APPEND)
- timestamp, pid = self.msgid.split('.')
+ timestamp, pid, ignore = self.msgid.split('.', 2)
# Remove Return-Path: to avoid duplicates.
del self.msgobj['return-path']
# Remove X-TMDA-Recipient:
@@ -469,7 +473,7 @@
if not self.confirm_accept_address:
if self.recipient:
import Cookie
- (timestamp, pid) = self.msgid.split('.')
+ (timestamp, pid, ignore) = self.msgid.split('.', 2)
self.confirm_accept_address = Cookie.make_confirm_address(
self.recipient, timestamp, pid,
'accept')
--
Michael Allan
Toronto, +1 416-699-9528
http://zelea.com/
|
|
From: Sabahattin G. <ma...@sa...> - 2011-06-10 08:15:51
|
On 10 Jun 2011, at 06:10, Kevin Goodsell wrote: > There was a request some time back to get the 8BITMIME capability added > to tmda-ofmipd: > http://sourceforge.net/mailarchive/message.php?msg_id=25325009 > > As I understand it, this requires possibly re-encoding messages to a > 7-bit format when transmitting to a host that doesn't advertise 8BITMIME > support. However, there's an interesting case made for a different > approach here: > http://cr.yp.to/smtp/8bitmime.html > > Since this requires virtually no effort to implement, it's appealing to me. I think, for tmda-ofmipd, the easiest and at the same time safest solution is to make it a command-line option, say -8, which decides whether or not 8BITMIME is advertised. Since the owner of tmda-ofmipd is also the one specifying the host to which mail is relayed, he can know in advance whether or not it will accept any eight-bit mail he may send via tmda-ofmipd. For this to work you will also need a config option in tmda-inject that will properly denote eight-bit mail using a command-line switch to sendmail (-B8BITMIME) or the equivalent SMTP parameter to MAIL From. See RFC 6152. While this does leave open the possibility of mail being designated 8BITMIME when it is in fact just 7BIT, in practice this probably isn't likely to be a problem. > Does anyone have any thoughts what approach to take? Also, I'm wondering > what difference 8BITMIME makes in practice. My mailer seems to send 8 > bits without this capability advertised, which makes testing tricky. If > I knew of use-cases that actually fail without 8BITMIME, that might > help. For example, Alpine will use the SMTP's advertisement to (by default) decide whether to just send 8 or QP-encode. Cheers, Sabahattin |
|
From: Kevin G. <kev...@gm...> - 2011-06-10 05:10:29
|
There was a request some time back to get the 8BITMIME capability added to tmda-ofmipd: http://sourceforge.net/mailarchive/message.php?msg_id=25325009 As I understand it, this requires possibly re-encoding messages to a 7-bit format when transmitting to a host that doesn't advertise 8BITMIME support. However, there's an interesting case made for a different approach here: http://cr.yp.to/smtp/8bitmime.html Since this requires virtually no effort to implement, it's appealing to me. Does anyone have any thoughts what approach to take? Also, I'm wondering what difference 8BITMIME makes in practice. My mailer seems to send 8 bits without this capability advertised, which makes testing tricky. If I knew of use-cases that actually fail without 8BITMIME, that might help. -Kevin |
|
From: Kevin G. <kev...@gm...> - 2011-05-21 17:17:05
|
I've just pushed several commits, mostly around adding IPv6 support (plus adding tests, fixing some minor issues). This primarily adds IPv6 support to tmda-ofmipd (though it also allows using the tmda-cgi simple-server in IPv6 mode to test tmda-cgi). There are several areas where IPv6 needed to be addressed: * Options for the address/port the server listens on. * Supporting IPv6 URL format for remote authentication (-R option). * Recognizing ::1 as a loopback address allowing non-TLS authentication with --tls=localoptional. * The ipauthmap file that allows selecting the remote authentication host based on the interface the client connected on. This includes some functional changes: * In addition to -p/--proxyport, there's a new -6/--ipv6proxyport option to specify on IPv6 address. These two options can appear multiple times, in any combination, to bind many address/port combinations. * With the above options, the preferred syntax for binding all available addresses is now ":PORT" instead of "0.0.0.0:PORT". The old version still works for IPv4 addresses. * ipauthmap has a new space-separated format instead of the colon-separated format previously used. The space-separated format is necessary to prevent ambiguity in IPv6 addresses. However, lines that only have IPv4 addresses can still use the old format. * Additionally, ipauthmap now supports comments at the ends of lines rather than only at the beginning, has its format checked more thoroughly, and is only read from disk the first time it is needed. The additional tests for all the new cases are fairly extensive, also adding coverage for old behavior that had no tests previously. -Kevin |
|
From: Kevin G. <kev...@gm...> - 2011-04-25 20:21:22
|
On Mon, Apr 25, 2011 at 12:53 PM, Sabahattin Gucukoglu <ma...@sa...> wrote: > Just a reminder to put it on a todo list somewhere, in case it isn't already yet. :-) > > It's not in the latest tmda-ofmipd. > It's definitely on the TODO list. In fact I started working on it again today. I'm looking at the possibility of changing the design a bit so that it can listen on multiple addresses at once (allowing IPv4 and IPv6 simultaneously, or multiple network interfaces). -Kevin |
|
From: Kevin G. <kev...@gm...> - 2011-04-21 01:25:20
|
On Wed, Apr 20, 2011 at 9:52 AM, Tim Rice <ti...@mu...> wrote: > > It looks like you can use the ones from a tmda-cgi-0.13 tarball > I'm convinced (by doing some svnadmin dumps and examining the output) that the images were corrupted in the repository. I don't know why I didn't think to check the source tars (I guess I forgot they were there), but this seems to have worked nicely. I've checked in the repaired images and changed all the svn properties to omit svn:keywords and svn:eol-style, and include svn:mime-type with the value image/gif. Thanks for the suggestion, Tim. -Kevin |
|
From: Tim R. <ti...@mu...> - 2011-04-20 16:52:31
|
On Tue, 19 Apr 2011, Kevin Goodsell wrote: > I've found many corrupted .gif files in tmda-cgi, mostly in > tmda-cgi/htdocs/display/ and various places in > tmda-cgi/display/themes/Blue. This *could* be because the files were > checked in with bad svn properties (especially svn:eol-style) which > would cause svn to rewrite the files on checkout (I think), in which > case the originals could still be in the repository. However, as a > test I fixed the properties on the files in tmda-cgi/display/icons and > this did not seem to make any difference for sound.gif, which is still > visibly distorted in those applications which don't simply fail to > open it. I ran md5 on all the .gif and .png files in tmda-cgi-0.13 and tmda-cgi-0.16.4. 37 of them were different. ....... display/icons/python.gif display/icons/sound.gif display/themes/Blue/button_templates/layout1_r1_c1.gif display/themes/Blue/button_templates/layout1_r2_c1.gif display/themes/Blue/button_templates/layout1_r3_c1.gif display/themes/Blue/button_templates/layout1_r4_c1.gif display/themes/Blue/button_templates/layout1_r5_c1.gif display/themes/Blue/button_templates/layout1_r6_c1.gif display/themes/Blue/button_templates/layout1_r7_c1.gif display/themes/Blue/buttons/options_r1_c2.gif display/themes/Blue/buttons/subnav_r1_c1.gif display/themes/Blue/buttons/subnav_r1_c12.gif display/themes/Blue/buttons/subnav_r1_c13.gif display/themes/Blue/buttons/subnav_r1_c14.gif display/themes/Blue/buttons/subnav_r1_c15.gif display/themes/Blue/buttons/subnav_r1_c16.gif display/themes/Blue/buttons/subnav_r1_c2.gif display/themes/Blue/buttons/subnav_r1_c4.gif display/themes/Blue/buttons/subnav_r1_c5.gif display/themes/Blue/buttons/subnav_r1_c6.gif display/themes/Blue/buttons/subnav_r1_c7.gif display/themes/Blue/buttons/subnav_r1_c8.gif display/themes/Blue/buttons/subnav_r1_c9.gif display/themes/Blue/corner.gif display/themes/Blue/flowchart/ld.gif display/themes/Blue/flowchart/left.gif display/themes/Blue/flowchart/lm.gif display/themes/Blue/flowchart/rd.gif display/themes/Blue/flowchart/right.gif display/themes/Blue/flowchart/rm.gif display/themes/Blue/login.gif display/themes/Blue/paperclip.gif display/themes/Blue/top_bg.gif htdocs/display/corner.gif htdocs/display/login.gif htdocs/display/paperclip.gif htdocs/display/top_bg.gif ....... Next I used feh to display each of them. In all cases the tmda-cgi-0.13 one looked OK. All but 10 of those 37 in tmda-cgi-0.16.4 looked corrupted. The ones I could not see a difference were: ...... display/themes/Blue/button_templates/layout1_r6_c1.gif display/themes/Blue/buttons/subnav_r1_c14.gif display/themes/Blue/buttons/subnav_r1_c15.gif display/themes/Blue/buttons/subnav_r1_c16.gif display/themes/Blue/buttons/subnav_r1_c2.gif display/themes/Blue/buttons/subnav_r1_c6.gif display/themes/Blue/buttons/subnav_r1_c7.gif display/themes/Blue/buttons/subnav_r1_c9.gif display/themes/Blue/top_bg.gif htdocs/display/top_bg.gif ...... > >From comparing hex dumps with good copies of some of these files > (found on the Sourceforge web site) it appears the 0x0D bytes have all > been changed to 0x0A, so that suggests they were incorrectly processed > as text somewhere along the line, and had their "EOL" markers changed. > > I'm concerned that the originals of some of these files may be lost. It looks like you can use the ones from a tmda-cgi-0.13 tarball -- Tim Rice Multitalents (707) 887-1469 ti...@mu... (707) 456-1146 |
|
From: Kevin G. <kev...@gm...> - 2011-04-20 02:43:54
|
I've found many corrupted .gif files in tmda-cgi, mostly in tmda-cgi/htdocs/display/ and various places in tmda-cgi/display/themes/Blue. This *could* be because the files were checked in with bad svn properties (especially svn:eol-style) which would cause svn to rewrite the files on checkout (I think), in which case the originals could still be in the repository. However, as a test I fixed the properties on the files in tmda-cgi/display/icons and this did not seem to make any difference for sound.gif, which is still visibly distorted in those applications which don't simply fail to open it. >From comparing hex dumps with good copies of some of these files (found on the Sourceforge web site) it appears the 0x0D bytes have all been changed to 0x0A, so that suggests they were incorrectly processed as text somewhere along the line, and had their "EOL" markers changed. I'm concerned that the originals of some of these files may be lost. The most pressing questions I have right now are: * Is there a way to make Subversion give me the raw file, as it is in the repository, with no translations whatsoever? * Does everybody see this corruption, regardless of their platform? (I'm on Linux.) * Are the original files available anywhere? In particular, the buttons and button templates for the "Blue" theme. -Kevin |
|
From: Andrew G. <ty...@ba...> - 2011-04-16 18:28:29
|
Just a note, CentOS (RHEL) 5 is still at 2.4.3. I don't know what RHEL 6 uses as I don't have any servers at that point since I primarily use CentOS and they haven't gotten v 6 out yet. I would anticipate something in the 2.6 or 2.7 line though as the latest Fedora (14) is on 2.7.8 That being said, I too am thrilled to see development going forward again on TMDA. I may just have to backport the newer python to CentOS so I can stay up to date. -Andy- On Tue, 2011-04-12 at 12:55 -0700, Tim Rice wrote: > On Tue, 12 Apr 2011, Kevin Goodsell wrote: > > > My suggestion for now is to make 2.5.x to 2.7.x the supported versions, > > with the intention of dropping 2.5.x in the not-to-distant future. > > > > Does anyone feel that support for versions as old as 2.4.x is still > > necessary? Or that 2.5.x will be necessary for an extended period of > > time? > > Yes, Solaris 10 uses 2.4.6. > That said, I'm thrilled that someone is actually doing further > development work on TMDA and if it is a lot of extra work to support > 2.4.x I'll build a newer version of python. > > > > > > -Kevin > |
|
From: Kevin G. <kev...@gm...> - 2011-04-14 02:29:26
|
On Wed, Apr 13, 2011 at 12:11 PM, Livia Santos <liv...@gm...> wrote: > Hi Kevin, > I'm sorry for not being clear. By "not working" I meant I looked at Apache's > log and got the following message: > [Tue Apr 12 17:11:21 2011] [error] [client xxx.xxx.xxx.xxx] malformed header > from script. Bad header= File "tmda-cgi.py", line 76,: tmda.cgi That looks suspiciously like the first line of a Python traceback message. With the whole message we would have a pretty good chance of determining what the problem is, but one line doesn't help much. If you can get the complete output from the CGI process that would help diagnose the problem (but I don't know how this would be done with Apache). -Kevin |
|
From: Kevin G. <kev...@gm...> - 2011-04-13 18:56:18
|
On Wed, Apr 13, 2011 at 11:26 AM, Lívia <liv...@gm...> wrote: > > Now I'm trying to install tmda-cgi 0.16.4 > but it's not working. "Not working" isn't much to go on. > > Does anybody know if this version of tmda-cgi > need a specific version of python? > > I'm using Python 2.6. Don't get your hopes up. tmda-cgi uses at least one old library (whrandom) that's been removed since Python 2.5 (deprecated since 2.1). That alone is easy enough to fix (just replace it with random), but it indicates how out-dated the code is, and it's hard to say what else might be broken. I'm trying to update tmda-cgi at the moment (literally, was working on it before I checked my mail and found this message), but I'm not interested in using it myself, which means I'm not very interested in maintaining it, and not very able to test it. In all likelihood it will take more than I have to give to get it into a good, reasonably tested and usable state. That said, you can try the slightly updated version in Subversion. Not much has changed in tmda-cgi itself, though. It's been slightly updated to not depend on a local copy of the email library, and the configuration script has been rewritten. Plus there's a simple testing server that might help diagnose any problems you are having (though its use isn't documented yet). -Kevin |
|
From: Lívia <liv...@gm...> - 2011-04-13 18:35:19
|
Hi, I'm not familiar to mail servers, but I have to install TMDA on a already working Postfix server. I read a lot of tutorials, but most of them explaining how to install TMDA to work with Maildrop. I need to make it work with procmail. So far I've installed TMDA 1.1.12 ok. I was told I need to create a file named ~/.procmailrc for each user 's home (although I dont't know its content yet... gonna find it somewhere...>D ). Now I'm trying to install tmda-cgi 0.16.4 but it's not working. Does anybody know if this version of tmda-cgi need a specific version of python? I'm using Python 2.6. Thanks in advance. Lívia. |
|
From: Tim R. <ti...@mu...> - 2011-04-12 19:55:12
|
On Tue, 12 Apr 2011, Kevin Goodsell wrote: > My suggestion for now is to make 2.5.x to 2.7.x the supported versions, > with the intention of dropping 2.5.x in the not-to-distant future. > > Does anyone feel that support for versions as old as 2.4.x is still > necessary? Or that 2.5.x will be necessary for an extended period of > time? Yes, Solaris 10 uses 2.4.6. That said, I'm thrilled that someone is actually doing further development work on TMDA and if it is a lot of extra work to support 2.4.x I'll build a newer version of python. > > -Kevin -- Tim Rice Multitalents (707) 887-1469 ti...@mu... (707) 456-1146 |
|
From: Jason R. M. <ja...@ma...> - 2011-04-12 19:49:45
|
I see no reason to support Python 2.4 and lower. I'd maintain 2.5 compatibility until it's prohibitive to the development process then drop that as well. The few users that still rely on old versions of Python still have the TMDA 1.1.x line available. On Tue, Apr 12, 2011 at 2:55 PM, Kevin Goodsell <kev...@gm...> wrote: > At this point I'm not sure it's exactly clear what Python versions are > supported, and I don't know off the top of my head if there's on > official requirement. I believe my releases have included dependencies > on Python 2.4, and some of my recent commits depend on Python 2.5 > features. > > Certainly supporting versions up to 2.7.x is desirable (and any future > 2.x versions, though I *think* 2.7 is expected to be the last in the > Python 2 line), and supporting 3.x is impractical until some significant > work is put into converting the entire code base. > > So the main question is the minimum supported version. Python 2.5 was > released in September of 2006, and is available in Debian's "oldstable" > release (Lenny) from February 2009. Since Debian has a reputation for > old software in its stable releases, something that's available as far > back as it's previous stable release seems more than reasonable. > > Python 2.6 seems reasonably widespread at this point, and was released in > October 2008. It's also the default version in the current Debian > release. > > My suggestion for now is to make 2.5.x to 2.7.x the supported versions, > with the intention of dropping 2.5.x in the not-to-distant future. > > Does anyone feel that support for versions as old as 2.4.x is still > necessary? Or that 2.5.x will be necessary for an extended period of > time? > > -Kevin > |
|
From: Kevin G. <kev...@gm...> - 2011-04-12 18:55:23
|
At this point I'm not sure it's exactly clear what Python versions are supported, and I don't know off the top of my head if there's on official requirement. I believe my releases have included dependencies on Python 2.4, and some of my recent commits depend on Python 2.5 features. Certainly supporting versions up to 2.7.x is desirable (and any future 2.x versions, though I *think* 2.7 is expected to be the last in the Python 2 line), and supporting 3.x is impractical until some significant work is put into converting the entire code base. So the main question is the minimum supported version. Python 2.5 was released in September of 2006, and is available in Debian's "oldstable" release (Lenny) from February 2009. Since Debian has a reputation for old software in its stable releases, something that's available as far back as it's previous stable release seems more than reasonable. Python 2.6 seems reasonably widespread at this point, and was released in October 2008. It's also the default version in the current Debian release. My suggestion for now is to make 2.5.x to 2.7.x the supported versions, with the intention of dropping 2.5.x in the not-to-distant future. Does anyone feel that support for versions as old as 2.4.x is still necessary? Or that 2.5.x will be necessary for an extended period of time? -Kevin |
|
From: Kevin G. <kev...@gm...> - 2011-04-09 23:41:23
|
On Sat, Apr 9, 2011 at 3:18 PM, Sabahattin Gucukoglu <ma...@sa...> wrote: > > Thanks, but I'm getting an Access Denied message trying to access the tmda-smtp package (but not the main installer package). > Thanks for letting me know. I hit a site glitch while uploading this package, but in the end it seemed to have worked. Apparently not. I've re-uploaded it now, and it looks like it's finally working. -Kevin |
|
From: Kevin G. <kev...@gm...> - 2011-04-09 22:08:11
|
On Sat, Apr 9, 2011 at 2:57 PM, Kevin Goodsell <kev...@gm...> wrote: > I've pushed two commits out to the Subversion repository as well as my > GitHub fork. On GitHub I've also tagged a new release (tag name > tmda-1.1.12-kg3 or debian-tmda-1.1.12-kg3-1 for the branch that > includes Debian packaging) and uploaded new .deb packages: > > https://github.com/KevinGoodsell/tmda-fork > > As indicated in the subject line, these changes are to address issues > that I consider security problems for tmda-ofmipd. Two separate issues > are addressed with these changes: > One thing I forgot to make clear in my message: these issues are specific to the OpenSSL version of tmda-ofmipd that has been available on the GitHub fork previously. The code was incorporated into the Subversion repository recently, but no official releases have ever included it. I have no particular reason to think that the TLSLite version has either of these problems (though I can't say I trust its security). -Kevin |
|
From: Kevin G. <kev...@gm...> - 2011-04-09 21:57:36
|
I've pushed two commits out to the Subversion repository as well as my GitHub fork. On GitHub I've also tagged a new release (tag name tmda-1.1.12-kg3 or debian-tmda-1.1.12-kg3-1 for the branch that includes Debian packaging) and uploaded new .deb packages: https://github.com/KevinGoodsell/tmda-fork As indicated in the subject line, these changes are to address issues that I consider security problems for tmda-ofmipd. Two separate issues are addressed with these changes: First, tmda-ofmipd allowed the use of SSL version 2, which is an older, insecure version of the protocol. It also allowed weak 40-bit and 56-bit ciphers. In all cases these were allowed because that is the default for the OpenSSL library. One of the changes adds a new --ciphers option to tmda-ofmipd, which allows the user to control which ciphersuites are accepted by the server. The default set excludes weak ciphers and SSL version 2 ciphers (though any user who really needs to can easily re-enable them). Second, tmda-ofmipd's error handling broke badly when SSL clients disconnected abruptly. This resulted in the process entering a tight, infinite loop and fixing the CPU usage at 100%, producing what could be considered a denial of service attack. There's also some indication that the server could be shut down remotely under some error conditions (this is not verified). The error handling has been significantly improved now, and tested against rapid-fire connects/disconnects, SSL protocol negotiation failures, and nmap scans. These issues probably aren't much more than a nuisance to most users, but I encourage any user of tmda-ofmipd (or the tmda-smtp Debian package) to upgrade. I will be turning my attention for a while to improving some of the tests for tmda-ofmipd, which I found to be lacking during the testing for this release. Following that I expect to return to tmda-cgi to do some cleanup work in preparation for the next official release. -Kevin |
|
From: Jason R. M. <ja...@ma...> - 2011-04-02 19:57:52
|
That's great Kevin. If anyone wants to try out the new code, I put links to tarballs of the trunk branch for tmda and tmda-cgi at the bottom of the downloads page: http://tmda.sourceforge.net/cgi-bin/moin.cgi/TmdaDownload On Sat, Apr 2, 2011 at 2:25 PM, Kevin Goodsell <kev...@gm...> wrote: > I just pushed a few more changes: > > * Remove pythonlib > * Some cleanup and minor fixes for tmda-cgi > * A simple web server for testing tmda-cgi > * A mostly new configure script for tmda-cgi, to support the web server > > Most of the actual work here was just to make tmda-cgi testable for > me, without having to install and configure a web server. > > One thing I am unable to test is the tmda/contrib/tmda.spec script for > RPM building. This had to be updated for the pythonlib removal, but as > a Debian user I don't have experience building RPMs and I'm not sure > exactly how this is supposed to be used. If anyone can test this and > notify the tmda-workers list of any problems, that would be > appreciated. > > Next I plan to do some additional updates to tmda-cgi, mostly to > remove deprecated items. > > I'm also keeping a github branch synchronized with the Subversion trunk here: > > https://github.com/KevinGoodsell/tmda-fork/tree/svn-trunk > > -Kevin > |
|
From: Kevin G. <kev...@gm...> - 2011-04-02 18:25:41
|
I just pushed a few more changes: * Remove pythonlib * Some cleanup and minor fixes for tmda-cgi * A simple web server for testing tmda-cgi * A mostly new configure script for tmda-cgi, to support the web server Most of the actual work here was just to make tmda-cgi testable for me, without having to install and configure a web server. One thing I am unable to test is the tmda/contrib/tmda.spec script for RPM building. This had to be updated for the pythonlib removal, but as a Debian user I don't have experience building RPMs and I'm not sure exactly how this is supposed to be used. If anyone can test this and notify the tmda-workers list of any problems, that would be appreciated. Next I plan to do some additional updates to tmda-cgi, mostly to remove deprecated items. I'm also keeping a github branch synchronized with the Subversion trunk here: https://github.com/KevinGoodsell/tmda-fork/tree/svn-trunk -Kevin |
|
From: Kevin G. <kev...@gm...> - 2011-03-30 16:49:03
|
On Wed, Mar 30, 2011 at 7:34 AM, David Grimberg <sen...@ba...> wrote: > Kevin, > > Now that you are maintaining/developing TMDA, would you consider adding this > patch to the code base? It's just an extension of the DB_CONFIRM_APPEND and > DB_BARE_APPEND variables to the PENDING_* variables. > OK, I've added it to the list of things to look at. -Kevin |
|
From: Jason R. M. <ja...@ma...> - 2011-03-18 18:26:09
|
Ok thanks. That's a mailing list that's no longer active. On Fri, Mar 18, 2011 at 10:23 AM, Kevin Goodsell <kev...@gm...> wrote: > I'm getting email errors from sourceforge because the email > notifications for checkins are going to an address that appears to no > longer be valid: > > Delay reason: SMTP error from remote mail server after RCPT > TO:<tmd...@tm...>: > host a.mx.tmda.net [66.135.48.124]: 450 4.1.1 <tmd...@tm...>: > Recipient address rejected: User unknown in local recipient table > > For the moment I've removed the hook that sends checkin notifications. > It can of course be restored if the address is fixed. > > -Kevin > |
|
From: Kevin G. <kev...@gm...> - 2011-03-18 17:24:01
|
I'm getting email errors from sourceforge because the email notifications for checkins are going to an address that appears to no longer be valid: Delay reason: SMTP error from remote mail server after RCPT TO:<tmd...@tm...>: host a.mx.tmda.net [66.135.48.124]: 450 4.1.1 <tmd...@tm...>: Recipient address rejected: User unknown in local recipient table For the moment I've removed the hook that sends checkin notifications. It can of course be restored if the address is fixed. -Kevin |
|
From: Jason R. M. <ja...@ma...> - 2011-03-18 16:25:49
|
Thanks for your work on this Kevin. I agree that now would be a good time to finally remove the pythonlib directory. On Wed, Mar 16, 2011 at 11:29 AM, Kevin Goodsell <kev...@gm...> wrote: > I just finished several commits taken from my GitHub TMDA branch here: > > https://github.com/KevinGoodsell/tmda-fork/wiki > > This is an almost-complete merge of my changes. The only thing missing > is the removal of the pythonlib directory and the copy of Python's > email library that lives there. There are some tweaks, combining of > commits, and addition of changelog entries, so the history isn't > identical to the GitHub history. > > Next I'd like to do some updates to tmda-cgi to remove deprecated > modules (this has already been done in tmda), consider removing > pythonlib (it seems unnecessary and a source of problems), and fix > some incorrect URLs in documentation, help output, etc. After that I > have some work in mind for tmda-ofmipd, mostly based on requests from > users (such as IPv6 support). > > The time I have available to work on this is limited, but I'd like to > try to get everything in a good, working state. > > -Kevin > |
