Headers are manually created whenever programmatically sending email messages

To clarify this a little, in case anyone isn't familiar, to send an email message programmatically, you basically just send a string with some headers and body content to the email server. Here are what the headers look like:

  Date: Sat, 13 Jun 2009 06:53:06 -0400
  From: Mail Delivery Subsystem <MAILER-DAEMON>
  Message-Id: <200906131053.n5DAr2Nv025105@jclinux>
  To: <root@jclinux>

To change the sender, all you'd need to do is change the from line. For example:

  From: Steve Jobs <[email protected]>

A default sendmail implementation will deliver that message all day. Email headers should never be used for authentication.

That was my point. When I read in his article that he wasn't requiring a password to post, I thought I'd see if he was telling the truth, turns out he was.

But most major domains use domain keys / DKIM.

http://en.wikipedia.org/wiki/DKIM

As far as I understand it, you can't fake being an SMTP server sending mail from such a domain because their emails get signed with a private key whose matching public key is published by DNS.

There are several ways to defeat DKIM here:

• If you can break DNS, you can get an NXDOMAIN reply, making recipients think there aren't any domainkeys

• If the domainkey private key is small, you can factor it. There's an article on HN's frontpage right now about this.

• If the server uses domainkeys, but it doesn't specifically verify the From: header, an attacker can still forge a message if they share a popular mail provider with their target. I don't know if this is still practical.

• Stupidity. DKIM is difficult to test, and as a security measure it would need to be tested.

An autoreponse confirmation would be immune to all of these attacks and would be trivial to implement correctly.

An auto-response confirmation would make posterous suck.

and yet DKIM is insecure for sender authentication.

As I understand it, they send you a mail telling you about the post and letting you remove it. Not perfect, but probably works 99% of the time.

99% of the time? So if someone decides to trash my reputation they can just post a bunch of stupid blog entries as me and it is on me to (a) detect that this even happened by checking my mail, (b) go do whatever work needed to remove the post and (c) try to explain to everyone what happened (likely causing even more people to do it when they realize how ridiculous the system I'm using is) and salvage my reputation?

That doesn't sound like "works 99% of the time" to me, that sounds like an epic fail.

EDIT: It appears that this was more of a configuration issue, so the above only applies if you set up your account this way.

You can already post a bunch of stupid blog comments as someone else, as long as people realize Posterous has a similar problem, it's not going to ruin your life. (Plus, (a) doesn't seem to be that big of a problem for a service you're using your email to access.)

Commenting on someone's site using a different name is pretty different from being able to fake a post. I have no expectation that comments are written by who they say they are, but I do expect all the posts to be written by the same person.

Clarification: by 99%, I meant it works for 99% of users, whom no one will ever try and attack. Obviously it's just my opinion.

Shouldn't it work oppositely? Prevent the post from appearing until you explicitly approve it from a link in an email.

Sort of defeats the purpose of Posterous though. It's nice to be able to send an email and be done with it. Though for an account coming under constant attack, it'd be nice to have the option though.

Edit: What they should really do is obfuscate the posting email addresses a little. Make my posting email [email protected], and give me the option to change it to something else if I am coming under attack.

I don't think it defeats the purpose, so to speak, since it's verified by another email. You never have to leave your email client.

It's certainly and extra step that takes away from the smooth flowing process already set in place, though.

Yes, and unless I'm missing something I don't see a way to turn this type of confirmation-before-posting functionality on.

I updated the post to reflect reality.

Usually, Posterous catches this stuff and sends an email asking you to confirm that you really are you. They analyze the headers more closely than just looking at the name. For some reason, this didn't work in this case.

According to him he just changed his email address to your email address in Outlook.

Edit: dcurtis edited his comment. Originally he claimed there was some kind of secret algorithm that prevents spoofing.

But, if they only analyse the headers, they are screwed anyway. Don't they also check the IP of the SMTP server as well or something?

Headers are name/value pairs, a typical email will have 20 of those. It's possible to copy them if you have received an email from the blog owner or maybe from a mailing list post.

You only need to know the owner's email address.

Access to a message or a mailing list post by them won't provide any further advantage.

Email address is not enough. This one case was a coincidence.

"We had a specific problem with the way we dealt with SPF records. Dustin didn't set any up, and there was a specific way that Robin Duckett's email server responded that caused us to flag it as a false negative for spoofing."

I think he said that: The blog owner's email host did not provide SPF protection; the intruder's email host appended some headers that lured Posterous to classify the email as genuine.

So, having access to the blog owner's email headers would not have provided any additional advantage to the intruder.

No, they don't.

I honestly am at a loss to understand how Dustin Curtis keeps getting linked from here.