Wandering Thoughts archives

2007-05-25

If you want work done, you need to pay for it

It's not news that if you want work done you usually need to pay people to do it; there are not that many selfless volunteers and sooner or later you stop being able to trick people into doing it for free. Of course, the open source movement is a clear demonstration that you don't have to pay people in money; people find any number of things rewarding. But you do need to give people a reward that they find meaningful.

(You can argue that a certain amount of open source's problems come when its lack of money means that it doesn't have adequate rewards for certain sorts of work. Any time you hear something called 'thankless', it is a good tipoff that no adequate reward for it exists.)

The more time the work will take, the higher the odds are that you will have to pay real money in order to get it done. Setting aside the speed at which you get results (perhaps you're very patient), there's a big difference between how many people are willing to devote an hour of spare time to something and how many people are willing to devote a thousand hours of spare time to something.

tech/PayForWork written at 23:19:40; Add Comment

The risks of spam filtering (part 1)

While spam filtering is 'dangerous' in that it can trigger on legitimate email, incorrectly classifying it as spam, there are different levels of dangerousness depending on what you do as a result of things triggering. In increasing levels of danger, there are three general things that people do:

  1. reject the email message during the SMTP conversion.
  2. discard the email message.
  3. bounce the email message back to the alleged sender.

The danger of the second option is obvious: the sender of a legitimate email message receives no indication that their email didn't reach the recipient. To them it looks just as if the recipient got it and is ignoring it, while to the recipient it looks like they never sent it in the first place.

The first and the third options both let senders of legitimate email know when their email didn't go through. The problem with the third option, and why it is the worst, is what happens with properly identified spam email. Most spam emails have forged sender information, which means that your mail server will be deluging innocent bystanders with what is effectively spam (to them); in the trade this is known as backscatter and makes people increasingly irate.

(Because of how spammers currently operate, rejecting email during the SMTP conversation is far less likely to do this, and if it does happen anyways it's not your fault because it's not your machine that is sending the bounces.)

Some spam filtering techniques don't explicitly reject email messages during SMTP conversations, but have a failure mode where your mail system never actually accepts the email and the sender's mail system eventually gives up on the message; the most well-known technique that can do this is greylisting. This is equivalent to rejecting the email during the SMTP conversation and has the same effects; if the sender is legitimate, they'll get a message that their email didn't go through, and if it's a spammer the message will probably just silently disappear.

(This is not unique to spam filtering; because modern mail systems insist that the domain of the sender address actually exists, persistent DNS issues can cause a similar 'defer until the sending machine times out the message' failure.)

spam/SpamFilteringRisksI written at 14:15:45; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.