rayners

Well, after a quick look at the server I'm on (4), it would seem that .foward is supported by Exim. I can't say for certain that is the case for all the servers, but I doubt any of them have it explicitly disabled. Where have you placed your .forward file?

You could probably do something with Procmail, which I'm sure is installed on the servers. You may have to create a .forward file to use it. I use it and SpamAssassin on my home machine (because I aggregate mail from a number of accounts). You only need one rule in your .procmailrc file to catch spam then: >:0: * ^X-Spam-Status: Yes caughtspam I put my spam in the "caughtspam" folder just in case I get some false positives, which I do get maybe once a month or so (and that's usually because they're mass mailings that I happened to have requested). You could just send it to /dev/null if you wanted.

Along the same lines, you might want to check out the Dive Into Accessibility "book" that Mark Pilgrim put together. Definately a good resource.

My understanding is that they mean that you have posted to that thread.

I think that may be a weird caching issue somewhere. I get that myself sometimes, and when I hit Refresh, it shows me as being logged in.

Here's a strange thought. Try taking the .pl out of the name. There may be some strange hiccup in the server config causing it to try and run the file instead of just sending it to the user because of the .pl in the filename. Files with the .gz extension have worked fine for many months on my site.

GPG should be installed, and it should be installed in /usr/bin/.

CSS is a wonderful thing. All of the layout spiffyness I do on my own site is done with pure CSS now.

If you're having any problems getting it setup, I can promise you that a number of us would be happy to help out.

I have it on good authority (Canadian friends of mine). According to them, up there it is illegal to out and out add caffine to something (i.e. Mtn. Dew or Jolt). Though I think it's okay if the caffine is already in there, like in Coke for example.

Want to know something aboslutely terrifying? Canadian Mt. Dew is caffine-free.

Well, for HTML::Template, you should be able to just drop in the module. In the directory you're running this script from, create an HTML directory, and place Template.pm in there (you can get it here). As for XML::Simple, I haven't tried this myself, but you should be able to do the same kind of thing. Create an XML directory in the script directory, and place Simple.pm in there (available here). I hope that helps. Good luck. I love CVS.

Well, they are based in Germany. The used to have an English language interface on their site, but that has since changed. If you can translate it, it's a great free account to have. I've never had any problems with it. I just don't use the web interface much anymore.

I've had great success with http://www.gmx.net. Though, I did get in before they changed their interface to be only German. Now I just use it as a POP account, so I don't even have to try and decipher it.

I imagine it's not so much a DNS issue as it is an Apache Virtual Host issue. If Apache knows that it's running under http://www.hispagimnasios.com/ (i.e. when the script is called with that as the base URL), it knows that the document root for that Virtual Host is /home/hispagi/public_html. If it is called with the IP number, it doesn't know that the page it is serving exists under http://www.hispagimnasios.com/, so the document root in that case is just the default server root (/usr/local/apache/htdocs). If that makes any sense.

Just a quick update. Since I've actually come up with a working name for the software, I changed the URL of the development blog. It is now residing at: http://blognplay.rayners.org/. It's nice to hear I've got so many fans.

Bah! That's what I get for telling people that I've been considering it. People actually want to see progress now. Anyways, just as a side note, one of the first steps in any system design is a Data Dictionary. Basically, it's just a list of words and what they mean, mostly so everybody is on the same page from the get-go.

Ahh, okay. Legal limitations. I thought you were talking about technical limitations. Simple licenses are a good thing as far as I'm concerned. Just to clear things up, there are two distinct things we are talking about here. First of all, a "patch." A patch is a modification to the source code of a core file in the system (for example the author archives patch I created many moons ago). Next, is a "plugin." A plugin is a file containing some amount of code that makes use of an API that the system provides to add additional functionality or capability to the system. Okay, now that we have the vocabulary ironed out, let me say that patches, while useful, are not always a good thing to be released to the masses. By altering the system, they alter the baseline, which starts up a complete support nightmare (among other things). Features or plugins may break, new bugs may be created, etc, etc. That's not to say that the patches shouldn't be generated. The best thing to do with a patch, in my opinion, is to make the software's author(s) aware of it and let them incorporate it into a future version. Now, if they chose not to, that's another story. Beyond that, plugins are great. They can extend the system in ways the original author(s) may never have even considered. By delegating a lot of the systems components to the plugin level, that allows the author(s) to concentrate on the system core. (Can you tell what direction I'm thinking of heading in for my own software ) Well, I just went ahead and created the development blog, though there's no actual content there yet. Maybe in a few days.

How so? What feels limited? Nothing wrong with reexamining, and, if necessary, redesigning, software every few years. Heck, that's what we've been doing at work for the last year or so. Do you think you could get a bit more specific than "patched" feeling? I don't really get the same feeling myself, but then again I'm hacking away at the source myself half the time. And I do agree that the plugins are starting to get a little out of hand. That's the main reason that Kristine started the MT Plugins Directory, why I got her to add the MT Plugins Bug Tracker, and why I'm writing the MT Plugin Manager. There's too many plugins out there to be easily handled manually. And in addition to just taking care of the installing, upgrading, and uninstalling, I'm shooting for the Plugin Manager to be a documentation provider as well. Docs are always handy. Well, I don't have anything in particular down on paper just yet. I've been thinking about putting up a site (http://blog.rayners.org/ or something along those lines) to just do some brainstorming and gather some user feedback to see what people think. Nothing is certainly set in stone yet, though I'm leaning more towards Perl for the "main" implementation, along with perhaps a PHP API to add on to it... Templating system.. Plugin interfaces out the wazoo.. yada yada yada..

What in particular do you guys think is bloated about MT? Needless to say, I've worked with it quite a bit, so I'm curious how it looks from the outside. I've been toying with the idea of writing my own blogging software, so it would be nice to hear what people think of existing solutions.

What in particular do you want to do that Mailman can't?

Are you sure you don't mean Mailman instead of FormMail? Those options sound pretty familiar to me. Anyways, the only option you need to check is the one to restrict posting privilege to list members. That way only people actually on the mailing list can send messages through it. Everything else is rejected.

My initial impression, this sounds to me like its a logic error somewhere in the program. If you can actually write to the file, that has already eliminated any issues you might be having with the system outside of the script. I'd be happy to take a quick look through the script and see if anything jumps out at me if you'd like. I can't promise I'll be able to find the time to do it anytime in the next week or so, but I'll try.

I imagine the path is most likely /usr/bin/gpg.

Well, if you just want to disable viewing of the directories through a browser, in CPanel, click on the Index Manager link in the Site Management section, and select the directory for which you'd like to disallow indexes. In the resulting page, select "No Indexes" and click the Save button. Voila! No more directory indexes there.