Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5182

When doing an import of a .mud from a blank session all status items will be created in the untiltled package instead of the correct package.

Procedure
1. Launch CMud
2. Press ESC to close the Sessions Window
3. Open Package Editor by clicking on Settings Button
4. Select File|Open from the Package Editor
5. Chose a .mud file with numerous status bar/window settings

Once the import is complete you will find all the status setting are in the untitled package. The matching class stucture will be created as the original .mud had it. The status settings are properly set as enabled and disabled matching the original .mud. The classes created in the untitled package do not have the original enabled/disabled state.

Posted: Fri Oct 12, 2007 6:01 pm

If you can email me the *.MUD file to sales@zuggsoft.com, I might be able to get this fixed in the next version. I wasn't able to reproduce it with some simple testing.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I just sent the file so you should have a good example to test shortly.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

It looks like the file I sent you before was messed up. I just sent a new one that looks to be correct for demonstrating this bug.

A small correction to the original report is that the first status setting is created in the correct package, all others are created one package off. So if you have 2 packages open and then open the .mud the status setting will end up in the second package and not the first.

I have been having some rather odd issues crop up that may be related to this bug. One of them is a complete hang of the package editor when trying to move a class to a new package. The particular class is the one that has the first status bar from original .mud. I am still working around to see if I can figure the exact cause.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The status item does not appear to be the problem that was making import impossible for me. New bug report to follow in another topic.

Posted: Sat Oct 13, 2007 6:30 pm

I haven't gotten a file yet. Did you send it to the sales@zuggsoft.com address? Make sure it is less than 5MB or else you might need to post it somewhere for me to get.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

File uploaded to Guru area. I wish that email filter would stop being so picky.

Posted: Mon Oct 15, 2007 10:54 pm

Yeah, I don't know what it is, but we get *so* much spam that I can't turn off the filters. We use Spam Assassin and a service called "Barracuda" that updates their rules regularly as new spam is analyzed. Without these filters we get over 3,000 spams a day, which is too much to deal with manually. With the filters I get about 10-20 spams a day that I delete manually. Since attachments are such a bad sign of spam, I think they make it difficult.

I'm not sure what file format you are using, but I regularly get *.PKG attachments from other people without a problem to our normal support@zuggsoft.com email. So maybe it's the *.ZIP that's causing the problem.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

On the spam thing - is it not possible to include a custom rule to allow anything with a .pkg attachment? I've used MessageLabs and I'm sure we had a similar requirement for certain files that MessageLabs were able to deal with.

Posted: Tue Oct 16, 2007 8:03 pm

It might be, but the Barracuda filters are on our actual email server, which is run by WolfPaw, so I don't have any direct control over those rules and settings.

The way our server works is that everything that comes into something@zuggsoft.com must pass the WolfPaw email server Barracuda filters. Those are usually set pretty strict, but I don't know what kind of attachment settings they have. I doubt they'd care about a *.pkg attachment, and I know I get other emails from other people with those attachments. Mostly I think it strips EXE, but I don't know about ZIP.

Then, the mail for support@zuggsoft goes into the HelpSpot web-based support system. It deals with attachments itself, and I definitely get emails containing *.pkg files there. HelpSpot has some of it's own spam rules, but stuff that fails goes into a Spam folder that I empty periodically, and I never see a "real" message in that spam folder. But because HelpSpot is web-based, it can have issues with some HTML mail clients. For example, the Feedback system in CMUD sends directly to HelpSpot and often messages containing XML or HTML scripts get cut off somewhere.

Mail for sales@zuggsoft (or any non "support" address) gets downloaded into our MDaemon local email server here. This is where additional SpamAssassin rules are run. We have some pretty severe filters on this server for attachments, viruses, etc, because this email ends up being viewed in Outlook, which is more susceptible to that kind of stuff than the HelpSpot web-based system. If the subject or body has "zmud" or "cmud" in it, then it shouldn't get filtered. And the "sales" account is less filtered than the other accounts.

Then, once the message gets to Outlook, some other rules are applied (sending sales messages to our database for example), but anything filtered at that stage goes into another spam folder that is usually pretty empty.

Anyway, that's probably more detail than I should really give on our current email system. The MDaemon server is the one that deleted over 3000 spams a day. I have no idea what the statistics on the Barracuda server is on the WolfPaw end, but I'm sure it's also pretty big.

So, I think it works better when you send *.PKG files directly, without putting them into a ZIP archive. It might also matter from what email provider you send it. I'm sure hotmail and gmail accounts are more heavily filtered than other email domains. But I try not to get involved with the Barracuda rules since they are used for all of the WolfPaw email customers. I was involved in testing this system when it was first added a couple of years ago and I never saw any real email that was treated as spam. But I'm sure the rules have changed over time. We certainly don't hear from customers that have tried to contact us and never gotten through. Usually it's the reverse...we get their email but can't reply because their email host is blocking our response for some reason.

All in all, email has gotten pretty bad. We have more and more trouble with people not getting our emails or their license keys. Some providers get really carried away with the spam prevention stuff. Mainly because spam is just such a huge problem. One of these days the entire email system is just going to become worthless and we'll be doing all support via web-based systems instead.

In any case, back to the topic at hand. Vijilante: if you wanted to send some test emails with and without various attachments to various email addresses of ours, I'd be happy to reply and let you know which ones we received. It's also possible that your own ISP is stripping the attachment as it goes out. But I'd be happy to try and track down the problem...who knows what we'll learn.

Wizard Joined: 14 Aug 2004 Posts: 1269

zuggsoft.com doesn't have an SPF record, so that may be a reason why some of your e-mails are being treated as suspected spam by some e-mail servers.
DNS Report for zuggsoft.com

Or just use nslookup
>set type=txt
>zuggsoft.com

You'll see the SOA record is returned (which is generally what happens where there is record of the type you requested).

Posted: Tue Oct 16, 2007 10:45 pm

Nice link Seb! I've never heard of SPF records before. I'll contact WolfPaw about this and see if they can add one to the nameserver. I haven't seen any trouble from hotmail (which claims to use SPF), but Yahoo was one of the "problem providers" for a while.

Unfortunately, it's probably one of those chicken and egg problems...providers don't add SPF unless they have to, and email providers can't require SPF because their users would complain when half their incoming email got filtered. The fact that I had never heard of SPF myself tells me that is hasn't been handled or publicized in the best way. Then again, I'm always behind the curve on this stuff.

Wizard Joined: 14 Aug 2004 Posts: 1269

Well, programs like SpamAssassin score messages based on a number of factors. Not having an SPF record in SpamAssassin (depending on how you have it set up) will probably just affect the score and therefore the likelyhood of a particular message being classed as spam - hence the intermittent problem, perhaps. Other mail servers may well have it set to either ignore SPF or reject or greylist mail that does not have it - in other one, almost an all or nothing situation. I don't think many servers have it like that, but my experience suggests it may be growing slowly. I implemented SPF at work recently in an attempt to get e-mail through to one or two of our customers (who used to receive e-mail from us fine before)... (Not actually sure what the end-result was though.) Also, make sure reverse DNS is set on all your IP addresses where genuine e-mails may come from. I also had to do this, which can be a bit annoying to do when you don't control your own PTR records (although I got it delegated to us).

Wizard Joined: 14 Aug 2004 Posts: 1269

Oh, also, you'll need to tell WolfPaw what to set as your SPF record so you'll need to go through the wizard on the site I linked to (or figure it out yourself) making sure that all your IP addresses or hosts are under the zuggsoft.com SPF umbrella.