_dan

There are plenty of services around that are capable of this sort of throughput. But I suspect you'd be better off with one catering to larger companies (rather than the Mailchimp/CampaignMonitor type that primarily deal with large number of smaller clients).

ReturnPath's stuff is a bit more advanced than that. They give you a large list of email addresses to send to (consisting of a number of webmail clients and ISPs). They then pick these up and provide stats on which have and haven't been delivered. They also ran your content through a number of spam filters (including, but not limited to SpamAssassin).

They also provide a whitelisting service (previously the "Bonded Sender" programme) which helps deliverability in a lot of cases, but the primary benefit is that it's pretty much the only way to guarantee delivery of large quantities of email to Hotmail.

So, they are closely involved with deliverability, but you're right in saying that it's down to Mailchimp to keep their sending IPs reputation clean.

Well, the really simple example is the string "postmaster". It is a perfectly legitimate email address, and almost always deliverable. But rarely something you want to actually accept.

I wish people would stop posting that. Yes, that covers most (though not all) of the RFC definitions of what constitutes an email address, but in practice you only want to accept a tiny subset of those.

> They desire harder and harder material

This is true, I know only too well. I started my pornography career as a young boy, and my tastes have got more and more depraved over the years.

Now I can only get off with pictures of completely naked women.

You got me ;)

The former. Even though it's 355 characters, at least it tells me it's a Google maps link. Which the shortened version doesn't.

There are some situations where URL shortening is arguably useful. But there's absolutely no reason why "microblogging" should be one of them.

Apart from the obvious (webdev bar, firebug, adblock, etc), I find HTTPFox (https://addons.mozilla.org/en-US/firefox/addon/6647) to be invaluable.

That's not unreasonable. My point was, make them dead easy to find for those that want them. But yes, there's probably something in having one at the bottom.

Not an easy one to test, though ;)

This is a really good set of guidelines. Here are the three most effective things you need to do (in my experience) to get and maintain decent delivery rates:

Remove your bounces. I cannot stress this enough. If you're sending using a homebrew system or a script on a webserver or what have you, make sure it can process bounces. Excessive attempts to deliver to dead addresses is the number one metric used by large email receivers to assess your mailserver IP's reputation.

Keep your list clean. Don't be tempted to add those 150 random names and addresses you found from last year's marketing push. It's not worth it. One or two bad records on your list is enough to completely decimate your delivery rates. Stick to double opt-in and don't be tempted.

Make your unsubscribe link obvious. Really obvious. Like, at the top of your email, or in big black text. Too many people feel the need to hide their unsubscribe link away in tiny text at the very bottom. If someone doesn't want your email, they have two choices - spambox it, or unsubscribe. If many people spambox your email - your delivery rates will suffer. Make unsubscribing easy and obvious.

You make a good point, but it really depends on the content of the email. For stuff that's mostly text, without much in the way of interesting links, "open" rates can be deceptively low and you could potentially be losing active readers if you remove them.

On the other hand, your email could be being spamboxed (or worse, blackholed) because half of your list has marked you as spam, and you're continuing to send to them once a week.

There isn't really an easy one-size-fits-all solution to that. Using a decent email service provider is a good idea, if you have the budget for it. They'll be able to give you a lot more information about your email's performance, likely have better delivery rates than your current mailserver (assuming you pick a provider that doesn't suck) and, importantly, will be able to identify and remove recipients who have marked your email as spam.

Edit: Deleting bounces, on the other hand, is extremely important, particularly if you have lots of webmail addresses. Possibly the most important thing you can do to maintain or improve delivery rates. That really should have been higher up on the list!

I do agree, but I don't think it was undeserved. They had a chance to replace a device that was considerably less durable than advertised, but refused to do so.

Judging by other reports in this thread (and other good things I've heard about Amazon's customer service), there's a decent chance they would have replaced it if he'd feigned ignorance and claimed it "just stopped working" - which means he told the truth from the outset.

His offer of a $400 settlement seems like a very reasonable number (I assume he had to pay to replace the ebooks he'd bought for it, plus the time without the device, and the $200 he'd paid for the replacement).

The only mistakes were on Amazon's part: selling an unreasonably delicate product, presenting evidence that supposedly proved its durability, and failing to replace it when it didn't live up to their claims.

A replacement device plus $200 seems very fair to me.

I use a little perl script, because it works everywhere I need it (and I suck at shell scripting ;))

    > cat `which title`
    #!/usr/bin/perl
    print(
        "\x1b",
        "]2;",
        join(' ', @ARGV),
        "\x7",
    );

Heh. You'd be surprised at how blasé a lot of companies are about people's personal information. The vast majority of the corporate world still thinks it's perfectly reasonable to do their work by emailing excel files of personal data around.

I've found that trying to get candidates to write code on the spot is often more trouble than it's worth. It can take ages to cover any significant ground, and nerves are always going to affect people in different ways.

If I find a promising-looking candidate, I send them a few really simple tasks to code up (nothing at all complicated, or particularly "academic", maybe an hour's work at the very most). I set no time limit, and even don't demand all the tasks are completed.

This serves as a very effective filter for quickly discarding the completely-useless (which easily comprises 70% of the applications we get), and for the rest gives me a pretty good insight into their abilities.

I've tried sending these tasks both before and after interviews, and I'm definitely in favour of sending them first and interviewing second.

Apart from the obvious stupid-filtering benefits, I've found it helps immensely in keeping interviews relaxed. Having seen some code, I have a vague baseline for their abilities, so I can start with something I know they're familiar with and slowly work towards more complicated and interesting topics (without having to drop any questions that are met with a blank stare).

Although getting example code after an interview is an interesting experience. My predictions about a candidate's performance based on an interview have proven, with alarming regularity, to be way off the mark.