This is a repost of the Pranketh avoid article.

The Problem

If Pranketh’s existence proves anything, it is that email is not the safest medium around. It has always been relatively easy to send an email that says it came from someone it did not, similar to the way one can write any return address on an envelope when sending a letter. So, now that Pranketh has made this problem very obvious, how can one determine if an email is what we call ‘spoofed‘?

Some email providers and programs show warnings on messages that may be spoofed, but the problem is that detecting spoofing is more art than science. A legitimate email may be spoofed (for example, if you write Pranketh and we write you back, we are actually writing you from our GMail accounts, but it will appear as though it came from Pranketh, which, in reality, it did) or a spoofed email may not be detected (because it also spoofs whatever the automatic detection system uses).

Message Headers

First of all, you’ll want to view what we call the ‘message headers’. Some of them (From, To, Subject) are always visible. Depending on your program, different ones will usually be hidden. The option to view them all may be called ‘View Message Headers’, ‘All Message Headers’, ‘Original Message’ or something similar. Below are some screenshots for two popular email services (more will be added as time goes on) :

View Headers in GMail

View Headers in Evolution

View Headers in Eudora

View Headers in Outlook

View Headers in Outlook Express

Now that the headers are visible, there are a few key things to check for. The first is a special header added by Pranketh to all emails it sends. If this header is there, we can be sure the email was sent using Pranketh! The line will likely be near the bottom and will look like this :

X-Joke: This email is not from whom it appears to be from. It was sent from pranketh.com.

What if someone is spoofing you without using Pranketh? Thankfully, there are other things you can check. You should see if there is a Return-Path header, similar to the following :

Return-Path: <singpolyma@sunkist.dreamhost.com>

The email-address-like part of that should be similar to who it says it is from (it does not have to be an exact match, but should be similar). If it is not similar at all (i.e., the above is on an email that says it is from bill@microsoft.com) then the email may be spoofed (see the next section for more on that ‘may’).

Another header to check for is ‘mailed-by’. For example, if an email claims to be from a GMail address it may have a header like the following :

mailed-by: gmail.com

That’s pretty simple.

If none of the above is present, or if it all checks out, you may want to checked the ‘Received’ section. It will look something like the following :

Received: from smarty.dreamhost.com (d06184b1.dreamhost.com [208.97.132.177])
by spaceymail-mx3.g.dreamhost.com (Postfix) with ESMTP id 8EF98188FC7
for <feedback@pranketh.com>; Wed, 16 May 2007 16:29:36 -0700 (PDT)
Received: from sunkist.dreamhost.com (sunkist.dreamhost.com [208.97.175.14])

by smarty.dreamhost.com (Postfix) with ESMTP id 7E510EE2C4
for <feedback@pranketh.com>; Wed, 16 May 2007 16:29:36 -0700 (PDT)
Received: by sunkist.dreamhost.com (Postfix, from userid 1429516)
id 81E63402A3; Wed, 16 May 2007 16:29:36 -0700 (PDT)

Notice how there are many references to dreamhost.com. That is because this email was sent from an address that lives there (actually, it was sent by Pranketh). A GMail email will have gmail.com, google.com, or googlemail.com there instead. A Hotmail email should have hotmail.com, etc.

Maybe Spoofed

Why in the above paragraphs did we say that if any of that was true the email ‘may’ be spoofed? Well, remember, detecting spoofing is more art than science. My email addresses all live on dreamhost.com and I send most of my email through GMail, but my email addresses are all at singpolyma.net. So how can you tell the difference between an email that’s spoofed on purpose by the person that owns it, or an email that is not from who it says it is? The best way is to check emails that you know are really from them. If they are spoofed in a similar way, then the email is likely legit. If they do not normally spoof their emails, or if the spoofing looks a lot different than normal, be very suspicious.

If you are not sure an email is really from someone, write them and ask if they sent it. That way, you can be absolutely sure.

Spread the Word

A lot of people trust email every day. It is our responsibility as people who know how to detect spoofing to spread the word. Link to this article, post it on your site, email it to friends, review it, translate it, anything that you think will get the word out faster!

We only ask that you give us credit and link back to this page according to the terms of a
Creative Commons Attribution-ShareAlike license.

How to Avoid Getting Pranketh’d, Scam’ed, or Phish’ed by Pranketh is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

I have updated this draft and released some code.

Regular readers of my blog know that I am obsessed with one thing: decentralisation. I hate having all my eggs in one basket. IMHO, if anyone has the ultimate power, then it’s not true Web 2.0. In my recent thinking this has extended to my view of social networks such as Facebook and MySpace.

One of the much-used features of these is personal messages. This can be public (ala Facebook wall) or private (ala Facebook message). I here intend to provide a TEP, which I will implement, suggesting a way to do this in a decentralised and RESTful manner.

Detecting the endpoint

I love XRDS! This format comes to us from the OpenID world but really provides a standard way to associate RESTful endpoints with a URL [example].

I think it makes most sense to have one type URL for this TEP and declare a namespace for extending XRDS to (optionally) tag endpoints with a ‘sub-type’. This could look like the following:

<?xml version="1.0" encoding="UTF-8"?><xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)" xmlns:dsn="http://singpolyma.net/dsn/xmlns">

<XRD>

<Service priority="50">

<Type>http://singpolyma.net/dsn/pmt

<URI>http://example.com/msg

<dsn:msgtype>private</dsn:msgtype>

</Service>

</XRD>

</xrds:XRDS>

(I will create these pages in a bit.) I would propose the following dsn:msgtype for now: private (only to you) and public (like Facebook wall). As this is a TEP, nothing is remotely final. I’m not sure I like msgtype as the tag name, for one thing.

Sending Data to the Endpoint

This part is easy. To support maximum compatibility with existing systems, either GET or POST data is to be accepted. All fields passed must be processed. The simplest system will simply take all data passed via both GET and POST and put the field name as a header and the value under/beside it in the message body. No data may be ignored (unless there is a particular value, such as a session ID, specific to your server which you want removed). The following is a list of fields which make sense to use in a special way. If you are going to do something special for one of these values you should use the name given here, but really any data can have anything done with it as long as it is included somewhere in the message.

subject, from (contact of sending user), cc, url (of sending user), name (of sending user), body

XHTML is allowed. Special data (such as calendar events) should be marked up with microformats where possible.

A way to contact the user back SHOULD be supplied. If either from or url is a URL, XRDS discovery can be performed on it in order to detect an endpoint for this TEP to use in replying.

I am going to write some code to implement this both for WordPress and independently soon. I may also create a simple service targeted at adding this capability to a blogger blog (or other locked-hosting website).

The idea is out: XMPP is a perfect replacement for SMTP.  SMTP (the current standard e-mail program) is outdated for a variety of reasons, such as the fact that it’s not SPAM resistant and that you can’t know for sure (easily) who sent a message.

XMPP (a.k.a. Jabber) solves a lot of this and is a fully extensible protocol that has already been adopted as a standard for IM.  The benefits are many, and there is only one major hurdle: every server on the Internet would have to change software!

Regular readers may be able to guess my (and others’) solution to that problem: backwards compatibility!  When using XMPP for primary email, one must provide a bridge back to the SMTP world.  There’s no real way around that for now.  Fortunately, it’s not too hard.  There are a few options:

1. Write a client that supports both XMPP and SMTP (through POP3 or IMAP) and have an identical address on both networks (think @gmail.com).
2. Modify (/write) an SMTP-based mail server to support XMPP.
3. Modify (/write) an XMPP server to support SMTP.

I really believe option #3 is the way to go.

What else may be required for this to become a reality?  Well, some way of keeping the traditional email experience (at least somewhat) may be required for the masses.  This means things like an inbox (for non-chat messages) and tags for message history.  Gmail actually already has this for offline messages.  There was also some work in 2004 on an XMPP client that supported something like this.

Some say that the encoding of emails must be retained.  I think this is bunk because it defeats the purpose of changing protocols and killing the old standard.  Some thought does need to go into the handling of offline payloads (especially file transfers / email attachments).  I think data: URIs may work for this, but something better may be in the works.

All it takes is one person who decides to adopt this as their primary way of functioning.  They develop some software, and it spreads from there.  I’m sticking with GTalk servers for Jabber for now (although I have the power to run my own @singpolyma.net), just because it’s easier for people who already have that address (I hate having multiple addresses).  What I’m really waiting for / looking for is a decent client for this.  Gmail has IM built in and handles this model for offline messages well, but it is not really even possible to reply to emails via Jabber, et cetera.  GTalk interfaces (including Gmail) actually don’t support any XMPP message type except chat well just yet.  We’re getting closer to something that could work though.

I’ve been reading Marc Andreessen’s blog for some time now, and have been ever impressed by the quality and range of content he’s putting out.  One of his recent posts dealt with some meta-conversation about blogging.  Is it better to comment or to post about something on your own blog?

He makes some great point against commenting.  Comments require filtering and moderation.  Comments also seem to encourage poorly written posts or small ‘me too’ which are not worth reading.

He also makes a rather big point about blogging.  Anyone can do it.  There are a number of free services (Blogger and WordPress.com among them) that let ANYONE EASILY blog.

I’m not ready to turn off comments here just yet, but I must say that this makes sense to me.  If you link to me I’ll find what you said.  If you trackback it still shows up here on the post.  I think there’s a place for commenting, maybe, but it’s definitely worth thinking about.

What do you think?  Comments, trackbacks, or both?

Friend Bookmarklets are something I’ve been playing with for awhile. WordPress users are no longer left out. With my new Friend Bookmarklets for WordPress plugin, users can generate a self-hosted friend bookmarklet to facilitate adding friends to the WordPress links system.