For leisure, cover-to-cover reading material - ebooks are extremely good at the task. I adore my Sony PRS-505 that I've used constantly for the past 2 years. All the pleasures of reading without the problems involved with storing dozens / hundreds of paper books. (And it's easy enough to convert from one format to another as long as you avoid buying DRM-encumbered ebooks.)
For reference material, where you have lots of page flipping or need to view intricate diagrams or reference tables - the smaller ebooks using eink with 1/4 sec response times are not suitable.
It's the "devil you know". XP has many pitfalls and issues, but it's well known, works well enough in a multitude of environments. It can run on systems from 256MB boxes with a 1GHz single-core CPU up to a 3.5GB unit with quad-core 3GHz.
Vista's design and launch was a complete disaster. Both from the technical side and from the PR side. Naturally, people are going to choose XP over Vista if given a choice if only for familiarity. Vista also launched right when the economy was headed into a recession - really bad timing. Not to mention that Vista came out ~2 years after it was supposed to and changed/broke a lot of things.
I suspect we'll see security updates for XP through at least 2014 or 2015. Microsoft will be forced to do so by the OEMs and large corps (and possibly the government).
I plan on setting up our first Win7 test box in the spring, and if it goes well, any machines purchased next summer/fall will be Win7 and we'll consider upgrading older PCs. (All of our "modern" PCs are dual-core with 2GB of RAM, so we're in good shape.) I believe that holds true for most other corps, test now, deploy sometime in 2010 at the earliest.
The other issue at hand is that PCs are no longer on a 3 year upgrade cycle. Most corps are now on a 4-5 year cycle or longer, and small business typically work on a 6-8 year cycle (skipping every other generation). Modern multi-core machines are going to have very long legs because the multi-core lets them stay responsive under heavy load, unlike the older single-core designs. Most users won't care if it takes a minute or two to print something, as long as the UI stays responsive (they can go check their email or look up something else).
Now you configure your video ripping, and a fucking CMD box pops up to do the actual work!
The blame for that lies in the hands of the people who wrote the encoding applications. They only provide a command-line client, with no nicely packaged library that could be used by other applications. (Or if they do, then the licenses aren't compatible.)
StaxRip does the same thing when encoding to x264, although it does manage to hide the command window, it's still simply passing arguments to a command line program.
Don't they have some, I dunno, science they could be telling us? Like a clip of the launch, or an explanation of the mission, or simulations of the orbit, or something?
Simply put... that requires a budget larger then shoestring and bailing twine.
Could the commentary be more interesting? Sure. We just need old astronauts to tell old space stories during the quiet portions of the broadcast.
I fail to see all good news for Firefox on that page. Or, should I say that I don't see all good news for consumers.
Together, IE6, IE7 and IE8 still dominate the market. I'm afraid that will remain true for a couple more years, no matter how much pressure the rest of the world puts on the market. Separating the versions of the various browsers just clutters the picture.
While I don't agree with the rosy picture being painted, I think it's fair to say that web developers should (can?) no longer code solely for Internet Explorer. Seeing IE's market share anywhere south of 90% makes it very easy to sell to managers that poor web design will tick off a significant share of their user base.
Back when it was only 5%, very few managers cared. Even at 10%, most would sniff and say "1 in 10" isn't worth the effort to make the site cross-browser. Now we're getting into the 20% range where business types get really uncomfortable with ticking off users.
It's like asking them, "Imagine if you told every 5th customer to walk through that door to shove off?"
Is it good new for Firefox? I think it's more good news for all alternate browsers as a whole. We're almost back to where we were around 2000 where there were many different browsers in use before IE sewed up the market for half a decade.
What would happen if you succeed and convert all internet users to firefox + adblock?
That's sorta why I go for NoScript + FlashBlock over AdBlock. Ads still display - unless they are powered by Javascript or Flash. So if your ad is a simple image or block of text, I'll still see it. But it won't annoy the heck out of me.
(The bigger reason I run NoScript/FlashBlock is to avoid malware being installed via Javascript / Flash.)
The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
If your mail server talks to the outside world, it must introduce itself properly. There's no wiggle room there.
Setup a 2nd SSHD daemon, with extremely restrictive settings (such as only letting one specific throw-away username that is a random mix of letters/numbers login).
My numbers (measured over a few hundred thousand messages) is that ~61% of all messages had SPF records, and we dropped 1/3 of those due to failing the "-all" check.
(Keeping in mind that we implement a few checks before this point, such as testing HELO records for RFC compliance and a basic DNSBL. So the really screwed up senders are already filtered out.)
First off, your mail server has to follow RFCs regarding HELOs. That means it has to be a valid HELO name, has to be a FQDN, and it has to map back to an address in a public DNS A/MX record. (We do *not* check beyond that as per the RFCs due to mail servers often being multi-homed and the IP address in the DNS record frequently won't match the IP address of the server that's talking to us.)
The HELO checks are cheap and will block 10-20% of inbound connections. Make sure you have a quick and easy way to whitelist servers which are improperly configured. You'll have to whitelist a few dozen during the first 2-3 months, then it will trickle down to about 1 per month.
Then I'd recommend blocking on a very very good DNSBL (like Spamhaus Zen). We personally choose not to.
After that, SPF checks and A/V filtering *during* SMTP time so that you can 5xx reject and not have to quarantine or deal with creating backscatter bounce messages. If you block using the Zen DNSBL, then you probably won't see many inbound viruses. But it's good to have A/V filtering at this point on inbound anyway. About 61% of our inbound messages have SPF rules that can be checked, and 33% of those get blocked at SMTP time due to "-all" failures.
At this point, we're dealing with maybe 40-50% of the original mail volume that was hitting our server. So now we feed it into a spam filtering system (we use SpamAsassin with amavisd-new). If you use Amavis, setup a 'soft' whitelist where you subtract 2 points for domains that you commonly do business with and subtract 5 points for specific email addresses which tend to score high.
We tag at 5.0 (adding a '[SPAM]' to the start of the subject line along with headers) and we quarantine at 9.0. The quarantine is simply done by moving the message into the user's Junk filter on the IMAP server using server-side Sieve filters. If the user wants to check their junk folder, they can either use webmail (which talks to the server via IMAP) or if they're already using an IMAP mail client, they can simply look in the subscribed Junk folder right in their mail client.
To give you an idea of numbers. Without the HELO checks and SPF checks, I would personally be getting about 6x more spam then I did before we implemented SA. We were killing off 83% of all spam just with HELO and a DNSBL check. With SA in the picture, I only see maybe 1/10th of what's left make it into my inbox. So we're keeping about 98% of all spam from hitting the user's inbox.
I could probably push that to 99%, but the risk of false positives would go up too much.
The problem with the technology is adoption rates. Unfortunately, many of these technologies are not being adopted by the masses. I'm not saying its hurting you by having these in place, but it also might not be doing as much good as you think that it is.
A quick check of mail volume:
151,000 messages checked in the log files that I looked at
58,800 (39%) did not have SPF records ('none')
So 61% of our inbound mail has SPF records that we can test. That is a pretty decent rate of adoption. (Note that we only test SPF for emails that make it past our first set of filters.)
Of the 92,200 messages with SPF records
51,650 (56%) passed their SPF check ('pass')
30,700 (33%) failed (-all)
5,150 (5.6%) resulted in a softfail (~all)
3,100 (3.4%) resulted in 'neutral' (?all)
1,500 (1.6%) permerror (DNS contains an invalid SPF record)
Killing off 33% of those messages with SPF records due to being obvious forgeries is still worth quite a bit. That lets us drop 20% of inbound spam at SMTP time without getting into the really heavy lifting of spam scoring or content analysis.
(We don't block on softfail, neutral or permerror conditions.)
The point of the ~all was so that you could start testing the waters.
We ran with ~all for a few years, but have recently switched everything over to -all.
So far, I've seen only 1 or 2 false positives where the SPF check failed - even when sent from our own mail servers. I'm guessing that the destination mail server had DNS troubles when it tested our message.
We've also started 5xx (rejecting) at SMTP time if the inbound message fails its SPF check. SPF has been around for long enough at this point, that mail admins who have implemented it *should* have the bugs worked out. (The time for excuses are past, and if we don't reject at SMTP time, the origin mail admin won't know things are broken.)
Sometimes you want to temporarily run your mail out a different IP or relay from another domain, and if you used SPF and your recipients have the dns record cached you are kinda screwed if you need to do anything in a hurry.
You solve that issue by running your SPF DNS records with a TTL of about 2 hours (or maybe 4 hours). Even in the freak accident category, I'm hard pressed to come up with a situation where your primary mail server goes up in flames (or the outbound ISP goes up in flames) and you can't both (a) move to a new host/IP range and (b) setup new SPF records in under 4 hours.
And if you can't manage to publish SPF records correctly, then don't. Full stop.
The rest of us will publish them. And manage our email infrastructure in a way that takes SPF records into account. Which means we'll have to deal with less joe-job forgeries then you will over the long run.
While I can accept that music would be less distracting that office chatter, I simply don't understand the concept that music is better than silence. I can work with music, but if I need to concentrate on something intensely, like a complex coding problem or making decisions based on a large amount of data, I need silence.
Music without vocals is a lot easier to concentrate to. It also needs to be non-novel, where you've listened to it enough that it is familiar to the brain.
My personal favorite for getting into the zone is either pure classical symphonies or 1-2 hour long dance (house/techno/etc) mixes (sans vocals). Because the pieces last for at least 45 minutes before switching to another track/style, you can get deep into the flow with music that is familiar.
(It's why I categorize my dance tracks by vocal / no-vocal along with approximate energy level of low/med/hi.)
Actually I would recommend that everyone browse at -1. There isn't really that much spam/trolling to contend with -- in exchange for having to scroll past one or two racist trolls you'll get to see raw unfiltered discussion that may not have survived the group think that permeates the moderation system.
The problem is that the/. comment display system chokes on pages with more then 100 comments if you like to read in Nested mode.
Sure, it shows you multiple pages, but the splitting logic is absolutely craptastic, resulting in duplicate messages appearing on multiple pages, and some comments can't even be seen if one of the nested root threads contains more then 100 messages.
So - I generally pick a score level that is
(There's a bug in the bug tracking system for this issue. It's at least 5 years old and probably over 8 years old. Which shows how crappy the slashdot comment display logic is.)
Eve *does* have instances--there are missions that DO instance you off from the rest of the player base.
No, EVE does not have instances. When you do a mission, even the tutorial missions, you're still in the same star system, it just picks a random point within your ship's range and tosses you there. You then get a magical "can't be scanned" bubble which prevents covert ops pilots from finding you with their scanning probes.
(That bubble vanishes after you end the mission. So if you're in lo-sec, always loot up before turning in the mission.)
I log into WoW now though and it feels more like I'm in a themepark called WoWLand than the game I used to play. It's like an amusement park meant to be just an imitation of Azeroth - let people hang out, get fake toys, and experience "attractions" in the form of instances rather than an actual challenge.
That analogy is completely on the mark.
They're trying to cater more and more towards the ADHD kids, who will immediately jump ship to the next shiny game that comes along, rather then take care of their core base of players who will stick around through thick and thin.
I swear that all of the "A" talent left the development team right after WotLK was released, and maybe even a month before. The entire WotLK experience has been one of adding "ooh shiny" bolt-ons rather then working within the original concept. I'm waiting for them to add mechwarrior vehicles that can morph from planes to boats to cars to walkers. Huge changes in difficulty of content. Instead of making a balanced change that is subtle and addresses the root cause, they simply nerf the content and slap a fresh coat of paint on it.
Level on meeting stones was stupid. Nothing like going to run a newbie through a lower level dungeon for some leveling gear, only to get there when you're 70 or 80 and get a "you can't use that stone, only for levels 40-50".
The meeting stones made a lot of sense back when they were introduced. The ranges were generous, and higher level folks have fast mounts to get around.
The problem came when they streamlined the dungeons so that instead of the mobs having up to 6 or 7 levels of variation, all the mob levels were compressed down to about 2-3 levels. At the same time, they tightened up the meeting stone level requirements. So a stone that you could've used before if you were slightly out of range was no longer useful. That was truly annoying.
The balanced and fair response would've been to slightly widen the stone's level range at the lower end (so you could be up to 5 levels lower then the dungeon) but to not put an upper level cap on using the stone. Therefore upper level players would be able to use the stones, but you wouldn't be able to abuse the stones to summon a level 15 player to the northern edge of Northrend (where they really have no business being).
Instead, they took the lazy way out and made all meeting stones identical. Which means that WoW takes yet another step down the road towards blandless geography, where one location is no better/different then another.
A world with trivial travel requirements is ultimately boring. It's darned convenient, but you lose a lot of the atmosphere of having a virtual fantasy world.
I'd guess you'll see more of that, now that badmouthing doesn't really work anymore with people being unable to really gauge who they're playing with in a PUG.
Blizzard's been running down that road of enabling cheaters / scammers to get away without reputation damage for quite a while now.
If you're mean towards other players you can now:
- Switch servers every 3 days (instead of 30 or 90 days)
- Switch factions every 3 days
- Change your name & character gender frequently (3 day timer)
- Use the cross-server PuGs to ninja everything without consequences
Basically, if you're a rich prick that can pay for changing servers, factions, names, it's a golden time to be playing WoW. You can scam, cheat, steal, ninja-loot to your heart's content and simply move from server to server after getting caught.
MozBackup is the best way. Or switch to an IMAP server where the server admins are backing up the mailbox files nightly. Or backup your Documents and Settings\username\Application Data\Thunderbird folder (on WinXP).
As for controlling HTML vs plain text... TB3 is slightly better then TB2, but still gets confused. For my primary account, I compose in HTML. However, if the message contains no special formatting, TB will always send the message as plain text. Which has a few problems of its own.
You can also somewhat force the issue by going to the Options, Format when composing the email. Unless you forgot and started the message in an account where you told TB to compose in plain text. At that point, you're screwed and can't toggle the compose window into HTML mode.
Basically, that issue boils down to a structural design issue inside the compose window. The code is written in such a way that you can't switch modes - at least not until they rewrite the entire compose window code. (Rumored for TB v4.)
Then there's also the ability to tell TB on a contact-by-contact basis that a particular recipient only wants plain text.
Given some of the other things they've added to TB3 (which makes it rather bloated), adding a tiny little calendar/task extension can hardly be considered "bloat".
And you can't complain about the size of the data either. Even the worst control-freaks probably won't have more then 30,000 tasks per year or 5,000 meetings per year. Which, compared to the mail volume of something like the Postfix, PostgreSQL, or Apache mailing lists is a drop in the bucket.
Basic Tasks & Calendaring belong in the mail client. Even non-technical non-power-users have a need for basic tasks & calendaring. Unless the operating system has a standard way of providing that service to applications (maybe OS X does this).
The big question right now is whether or not I risk using a x.0 version release. Maybe I'll let others be the guinea pigs for right now.
I ran the TB 3 betas for most of '09. Beta 2 and 3 were prone to crashing every now and then (2 more then 3). Beta 4 introduced a whole can of new worms, but stopped crashing. RC2 has been pretty stable for the last 2 weeks.
So, if you're an IMAP user (all email is kept on the server), it's not terribly risky, except maybe for the chance of losing your address book. Which is something I've never seen happen. I only mention it because it's not stored on the IMAP server and you have to do local backups to keep it safe.
All that being said, they were already building 3.0.1 nightlies as of 2 weeks ago (around the time that they released the 3rd build for RC1). So it probably won't be too terribly long before you see 3.0.1 released.
There's also already a 3.1 set of nightlies (started about 2 months ago). So that's already in the pipe as well.
in Postfix's main.cf will get rid of about 97% of spam attempts (made up number). Of course, if you expect mail from those countries, you'll have to allow them.
Enforcing helo name sanity in Postfix will, by itself, drop your load by 50-60%. Even without querying external DNSBLs.
Start with "reject_invalid_helo_hostname", then "reject_non_fqdn_helo_hostname" and finally "reject_unknown_helo_hostname" (if you're using Postfix 2.6 or later). The last check isn't especially safe on a loaded mail server where DNS lookups might timeout or error out, but 2.6 fixes that so that reject changes to a defer if things go pear shaped. Add a ClamAV milter (possibly with custom rules from "sought" or "SaneSecurity). The last check you might want to do at SMTP time is a SPF policy check where you reject if the HELO or MAIL FROM violates the SPF policy listed in the DNS records of the sender. All of those checks will probably cut 65-75% of your inbound traffic from even needing to be filtered.
For mail systems where you have a lot of users, or a diverse user base, rejecting using a DNSBL is very risky. Far better to use those DNSBLs inside of a scoring filter like SpamAssassin (via amavisd-new) where DNSBL hits will contribute to bumping the spam score higher. DNSBL rejects work fine for smaller servers, or maybe using only the top-shelf DNSBLs like Spamhaus' Zen list.
(There's just too many crap DNSBLs out there, the risk of a false-positive reject is too high for a corporate / business mail server.)
Slashdot Mirror
For leisure, cover-to-cover reading material - ebooks are extremely good at the task. I adore my Sony PRS-505 that I've used constantly for the past 2 years. All the pleasures of reading without the problems involved with storing dozens / hundreds of paper books. (And it's easy enough to convert from one format to another as long as you avoid buying DRM-encumbered ebooks.)
For reference material, where you have lots of page flipping or need to view intricate diagrams or reference tables - the smaller ebooks using eink with 1/4 sec response times are not suitable.
It's the "devil you know". XP has many pitfalls and issues, but it's well known, works well enough in a multitude of environments. It can run on systems from 256MB boxes with a 1GHz single-core CPU up to a 3.5GB unit with quad-core 3GHz.
Vista's design and launch was a complete disaster. Both from the technical side and from the PR side. Naturally, people are going to choose XP over Vista if given a choice if only for familiarity. Vista also launched right when the economy was headed into a recession - really bad timing. Not to mention that Vista came out ~2 years after it was supposed to and changed/broke a lot of things.
I suspect we'll see security updates for XP through at least 2014 or 2015. Microsoft will be forced to do so by the OEMs and large corps (and possibly the government).
I plan on setting up our first Win7 test box in the spring, and if it goes well, any machines purchased next summer/fall will be Win7 and we'll consider upgrading older PCs. (All of our "modern" PCs are dual-core with 2GB of RAM, so we're in good shape.) I believe that holds true for most other corps, test now, deploy sometime in 2010 at the earliest.
The other issue at hand is that PCs are no longer on a 3 year upgrade cycle. Most corps are now on a 4-5 year cycle or longer, and small business typically work on a 6-8 year cycle (skipping every other generation). Modern multi-core machines are going to have very long legs because the multi-core lets them stay responsive under heavy load, unlike the older single-core designs. Most users won't care if it takes a minute or two to print something, as long as the UI stays responsive (they can go check their email or look up something else).
Now you configure your video ripping, and a fucking CMD box pops up to do the actual work!
The blame for that lies in the hands of the people who wrote the encoding applications. They only provide a command-line client, with no nicely packaged library that could be used by other applications. (Or if they do, then the licenses aren't compatible.)
StaxRip does the same thing when encoding to x264, although it does manage to hide the command window, it's still simply passing arguments to a command line program.
Don't they have some, I dunno, science they could be telling us? Like a clip of the launch, or an explanation of the mission, or simulations of the orbit, or something?
Simply put... that requires a budget larger then shoestring and bailing twine.
Could the commentary be more interesting? Sure. We just need old astronauts to tell old space stories during the quiet portions of the broadcast.
I fail to see all good news for Firefox on that page. Or, should I say that I don't see all good news for consumers.
Together, IE6, IE7 and IE8 still dominate the market. I'm afraid that will remain true for a couple more years, no matter how much pressure the rest of the world puts on the market. Separating the versions of the various browsers just clutters the picture.
While I don't agree with the rosy picture being painted, I think it's fair to say that web developers should (can?) no longer code solely for Internet Explorer. Seeing IE's market share anywhere south of 90% makes it very easy to sell to managers that poor web design will tick off a significant share of their user base.
Back when it was only 5%, very few managers cared. Even at 10%, most would sniff and say "1 in 10" isn't worth the effort to make the site cross-browser. Now we're getting into the 20% range where business types get really uncomfortable with ticking off users.
It's like asking them, "Imagine if you told every 5th customer to walk through that door to shove off?"
Is it good new for Firefox? I think it's more good news for all alternate browsers as a whole. We're almost back to where we were around 2000 where there were many different browsers in use before IE sewed up the market for half a decade.
What would happen if you succeed and convert all internet users to firefox + adblock?
That's sorta why I go for NoScript + FlashBlock over AdBlock. Ads still display - unless they are powered by Javascript or Flash. So if your ad is a simple image or block of text, I'll still see it. But it won't annoy the heck out of me.
(The bigger reason I run NoScript/FlashBlock is to avoid malware being installed via Javascript / Flash.)
RFC 5321 has replaced RFC 2821.
The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.
If your mail server talks to the outside world, it must introduce itself properly. There's no wiggle room there.
Setup a 2nd SSHD daemon, with extremely restrictive settings (such as only letting one specific throw-away username that is a random mix of letters/numbers login).
My numbers (measured over a few hundred thousand messages) is that ~61% of all messages had SPF records, and we dropped 1/3 of those due to failing the "-all" check.
(Keeping in mind that we implement a few checks before this point, such as testing HELO records for RFC compliance and a basic DNSBL. So the really screwed up senders are already filtered out.)
We run a multi-step system.
First off, your mail server has to follow RFCs regarding HELOs. That means it has to be a valid HELO name, has to be a FQDN, and it has to map back to an address in a public DNS A/MX record. (We do *not* check beyond that as per the RFCs due to mail servers often being multi-homed and the IP address in the DNS record frequently won't match the IP address of the server that's talking to us.)
The HELO checks are cheap and will block 10-20% of inbound connections. Make sure you have a quick and easy way to whitelist servers which are improperly configured. You'll have to whitelist a few dozen during the first 2-3 months, then it will trickle down to about 1 per month.
Then I'd recommend blocking on a very very good DNSBL (like Spamhaus Zen). We personally choose not to.
After that, SPF checks and A/V filtering *during* SMTP time so that you can 5xx reject and not have to quarantine or deal with creating backscatter bounce messages. If you block using the Zen DNSBL, then you probably won't see many inbound viruses. But it's good to have A/V filtering at this point on inbound anyway. About 61% of our inbound messages have SPF rules that can be checked, and 33% of those get blocked at SMTP time due to "-all" failures.
At this point, we're dealing with maybe 40-50% of the original mail volume that was hitting our server. So now we feed it into a spam filtering system (we use SpamAsassin with amavisd-new). If you use Amavis, setup a 'soft' whitelist where you subtract 2 points for domains that you commonly do business with and subtract 5 points for specific email addresses which tend to score high.
We tag at 5.0 (adding a '[SPAM]' to the start of the subject line along with headers) and we quarantine at 9.0. The quarantine is simply done by moving the message into the user's Junk filter on the IMAP server using server-side Sieve filters. If the user wants to check their junk folder, they can either use webmail (which talks to the server via IMAP) or if they're already using an IMAP mail client, they can simply look in the subscribed Junk folder right in their mail client.
To give you an idea of numbers. Without the HELO checks and SPF checks, I would personally be getting about 6x more spam then I did before we implemented SA. We were killing off 83% of all spam just with HELO and a DNSBL check. With SA in the picture, I only see maybe 1/10th of what's left make it into my inbox. So we're keeping about 98% of all spam from hitting the user's inbox.
I could probably push that to 99%, but the risk of false positives would go up too much.
The problem with the technology is adoption rates. Unfortunately, many of these technologies are not being adopted by the masses. I'm not saying its hurting you by having these in place, but it also might not be doing as much good as you think that it is.
A quick check of mail volume:
151,000 messages checked in the log files that I looked at
58,800 (39%) did not have SPF records ('none')
So 61% of our inbound mail has SPF records that we can test. That is a pretty decent rate of adoption. (Note that we only test SPF for emails that make it past our first set of filters.)
Of the 92,200 messages with SPF records
51,650 (56%) passed their SPF check ('pass')
30,700 (33%) failed (-all)
5,150 (5.6%) resulted in a softfail (~all)
3,100 (3.4%) resulted in 'neutral' (?all)
1,500 (1.6%) permerror (DNS contains an invalid SPF record)
Killing off 33% of those messages with SPF records due to being obvious forgeries is still worth quite a bit. That lets us drop 20% of inbound spam at SMTP time without getting into the really heavy lifting of spam scoring or content analysis.
(We don't block on softfail, neutral or permerror conditions.)
The point of the ~all was so that you could start testing the waters.
We ran with ~all for a few years, but have recently switched everything over to -all.
So far, I've seen only 1 or 2 false positives where the SPF check failed - even when sent from our own mail servers. I'm guessing that the destination mail server had DNS troubles when it tested our message.
We've also started 5xx (rejecting) at SMTP time if the inbound message fails its SPF check. SPF has been around for long enough at this point, that mail admins who have implemented it *should* have the bugs worked out. (The time for excuses are past, and if we don't reject at SMTP time, the origin mail admin won't know things are broken.)
Sometimes you want to temporarily run your mail out a different IP or relay from another domain, and if you used SPF and your recipients have the dns record cached you are kinda screwed if you need to do anything in a hurry.
You solve that issue by running your SPF DNS records with a TTL of about 2 hours (or maybe 4 hours). Even in the freak accident category, I'm hard pressed to come up with a situation where your primary mail server goes up in flames (or the outbound ISP goes up in flames) and you can't both (a) move to a new host/IP range and (b) setup new SPF records in under 4 hours.
And if you can't manage to publish SPF records correctly, then don't. Full stop.
The rest of us will publish them. And manage our email infrastructure in a way that takes SPF records into account. Which means we'll have to deal with less joe-job forgeries then you will over the long run.
DKIM solves a different problem, the two solutions (SPF vs DKIM) are not mutually exclusive.
While I can accept that music would be less distracting that office chatter, I simply don't understand the concept that music is better than silence. I can work with music, but if I need to concentrate on something intensely, like a complex coding problem or making decisions based on a large amount of data, I need silence.
Music without vocals is a lot easier to concentrate to. It also needs to be non-novel, where you've listened to it enough that it is familiar to the brain.
My personal favorite for getting into the zone is either pure classical symphonies or 1-2 hour long dance (house/techno/etc) mixes (sans vocals). Because the pieces last for at least 45 minutes before switching to another track/style, you can get deep into the flow with music that is familiar.
(It's why I categorize my dance tracks by vocal / no-vocal along with approximate energy level of low/med/hi.)
Actually I would recommend that everyone browse at -1. There isn't really that much spam/trolling to contend with -- in exchange for having to scroll past one or two racist trolls you'll get to see raw unfiltered discussion that may not have survived the group think that permeates the moderation system.
/. comment display system chokes on pages with more then 100 comments if you like to read in Nested mode.
The problem is that the
Sure, it shows you multiple pages, but the splitting logic is absolutely craptastic, resulting in duplicate messages appearing on multiple pages, and some comments can't even be seen if one of the nested root threads contains more then 100 messages.
So - I generally pick a score level that is
(There's a bug in the bug tracking system for this issue. It's at least 5 years old and probably over 8 years old. Which shows how crappy the slashdot comment display logic is.)
Eve *does* have instances--there are missions that DO instance you off from the rest of the player base.
No, EVE does not have instances. When you do a mission, even the tutorial missions, you're still in the same star system, it just picks a random point within your ship's range and tosses you there. You then get a magical "can't be scanned" bubble which prevents covert ops pilots from finding you with their scanning probes.
(That bubble vanishes after you end the mission. So if you're in lo-sec, always loot up before turning in the mission.)
I log into WoW now though and it feels more like I'm in a themepark called WoWLand than the game I used to play. It's like an amusement park meant to be just an imitation of Azeroth - let people hang out, get fake toys, and experience "attractions" in the form of instances rather than an actual challenge.
That analogy is completely on the mark.
They're trying to cater more and more towards the ADHD kids, who will immediately jump ship to the next shiny game that comes along, rather then take care of their core base of players who will stick around through thick and thin.
I swear that all of the "A" talent left the development team right after WotLK was released, and maybe even a month before. The entire WotLK experience has been one of adding "ooh shiny" bolt-ons rather then working within the original concept. I'm waiting for them to add mechwarrior vehicles that can morph from planes to boats to cars to walkers. Huge changes in difficulty of content. Instead of making a balanced change that is subtle and addresses the root cause, they simply nerf the content and slap a fresh coat of paint on it.
Level on meeting stones was stupid. Nothing like going to run a newbie through a lower level dungeon for some leveling gear, only to get there when you're 70 or 80 and get a "you can't use that stone, only for levels 40-50".
The meeting stones made a lot of sense back when they were introduced. The ranges were generous, and higher level folks have fast mounts to get around.
The problem came when they streamlined the dungeons so that instead of the mobs having up to 6 or 7 levels of variation, all the mob levels were compressed down to about 2-3 levels. At the same time, they tightened up the meeting stone level requirements. So a stone that you could've used before if you were slightly out of range was no longer useful. That was truly annoying.
The balanced and fair response would've been to slightly widen the stone's level range at the lower end (so you could be up to 5 levels lower then the dungeon) but to not put an upper level cap on using the stone. Therefore upper level players would be able to use the stones, but you wouldn't be able to abuse the stones to summon a level 15 player to the northern edge of Northrend (where they really have no business being).
Instead, they took the lazy way out and made all meeting stones identical. Which means that WoW takes yet another step down the road towards blandless geography, where one location is no better/different then another.
A world with trivial travel requirements is ultimately boring. It's darned convenient, but you lose a lot of the atmosphere of having a virtual fantasy world.
I'd guess you'll see more of that, now that badmouthing doesn't really work anymore with people being unable to really gauge who they're playing with in a PUG.
Blizzard's been running down that road of enabling cheaters / scammers to get away without reputation damage for quite a while now.
If you're mean towards other players you can now:
- Switch servers every 3 days (instead of 30 or 90 days)
- Switch factions every 3 days
- Change your name & character gender frequently (3 day timer)
- Use the cross-server PuGs to ninja everything without consequences
Basically, if you're a rich prick that can pay for changing servers, factions, names, it's a golden time to be playing WoW. You can scam, cheat, steal, ninja-loot to your heart's content and simply move from server to server after getting caught.
it was never clear to me how to backup msgs
MozBackup is the best way. Or switch to an IMAP server where the server admins are backing up the mailbox files nightly. Or backup your Documents and Settings\username\Application Data\Thunderbird folder (on WinXP).
As for controlling HTML vs plain text... TB3 is slightly better then TB2, but still gets confused. For my primary account, I compose in HTML. However, if the message contains no special formatting, TB will always send the message as plain text. Which has a few problems of its own.
You can also somewhat force the issue by going to the Options, Format when composing the email. Unless you forgot and started the message in an account where you told TB to compose in plain text. At that point, you're screwed and can't toggle the compose window into HTML mode.
Basically, that issue boils down to a structural design issue inside the compose window. The code is written in such a way that you can't switch modes - at least not until they rewrite the entire compose window code. (Rumored for TB v4.)
Then there's also the ability to tell TB on a contact-by-contact basis that a particular recipient only wants plain text.
Making it mandatory just seems like bloat.
Given some of the other things they've added to TB3 (which makes it rather bloated), adding a tiny little calendar/task extension can hardly be considered "bloat".
And you can't complain about the size of the data either. Even the worst control-freaks probably won't have more then 30,000 tasks per year or 5,000 meetings per year. Which, compared to the mail volume of something like the Postfix, PostgreSQL, or Apache mailing lists is a drop in the bucket.
Basic Tasks & Calendaring belong in the mail client. Even non-technical non-power-users have a need for basic tasks & calendaring. Unless the operating system has a standard way of providing that service to applications (maybe OS X does this).
The big question right now is whether or not I risk using a x.0 version release. Maybe I'll let others be the guinea pigs for right now.
I ran the TB 3 betas for most of '09. Beta 2 and 3 were prone to crashing every now and then (2 more then 3). Beta 4 introduced a whole can of new worms, but stopped crashing. RC2 has been pretty stable for the last 2 weeks.
So, if you're an IMAP user (all email is kept on the server), it's not terribly risky, except maybe for the chance of losing your address book. Which is something I've never seen happen. I only mention it because it's not stored on the IMAP server and you have to do local backups to keep it safe.
All that being said, they were already building 3.0.1 nightlies as of 2 weeks ago (around the time that they released the 3rd build for RC1). So it probably won't be too terribly long before you see 3.0.1 released.
There's also already a 3.1 set of nightlies (started about 2 months ago). So that's already in the pipe as well.
Nightly builds
comm-central-trunk - looks like the 3.1 branch
comm-1.9.1 - now the 3.0.1 branch (was the 3.0)
mozilla1.8 - this is the old legacy v2 product
in Postfix's main.cf will get rid of about 97% of spam attempts (made up number). Of course, if you expect mail from those countries, you'll have to allow them.
Enforcing helo name sanity in Postfix will, by itself, drop your load by 50-60%. Even without querying external DNSBLs.
Start with "reject_invalid_helo_hostname", then "reject_non_fqdn_helo_hostname" and finally "reject_unknown_helo_hostname" (if you're using Postfix 2.6 or later). The last check isn't especially safe on a loaded mail server where DNS lookups might timeout or error out, but 2.6 fixes that so that reject changes to a defer if things go pear shaped. Add a ClamAV milter (possibly with custom rules from "sought" or "SaneSecurity). The last check you might want to do at SMTP time is a SPF policy check where you reject if the HELO or MAIL FROM violates the SPF policy listed in the DNS records of the sender. All of those checks will probably cut 65-75% of your inbound traffic from even needing to be filtered.
For mail systems where you have a lot of users, or a diverse user base, rejecting using a DNSBL is very risky. Far better to use those DNSBLs inside of a scoring filter like SpamAssassin (via amavisd-new) where DNSBL hits will contribute to bumping the spam score higher. DNSBL rejects work fine for smaller servers, or maybe using only the top-shelf DNSBLs like Spamhaus' Zen list.
(There's just too many crap DNSBLs out there, the risk of a false-positive reject is too high for a corporate / business mail server.)