1. Scaling Communications (or, the Right Tool for the job)

    body

    I've been interested in different forms of communication for some time.  It's part of what makes social networking so interesting to me.  I've been reading about others' experiences too.  Of course there's Tantek's CommunicationProtocols page, which inspired my own Communication Protocols section on my main page (and, probably, @seanbonner's PreferedMeansOfContact).  Trevor Creech recently challenged me on my Twitter usage, calling it "Twitterfail" (in reference to efail).  I would like to discuss some of they ways I've started thinking about communication.

    First, a tip from my own main page: If you find a solution, from me or elsewhere, blog it. Someone else may benefit.  I have come to think of my Twitter and Ma.gnolia accounts as blogs (especially since they began to manifest their updates in the actionstream on my main page).  If I find an interesting tidbit, or have a potentially interesting thought, I tweet it.  This lead, one day, to >20 tweets in 24 hours, the condition which Trevor complained about.  In response, I have tried to consider first if something is really useful at all before I tweet (I don't want to be the cause of a signal/noise problem) - but I have also started including better context in my tweets.  Interesting links go to Ma.gnolia.

    Searchability has become key for me. This is one of the reasons I love my IM setup - everything anyone says to me, whether I'm online or off, at my computer or not, is archived in Gmail for easy search.  My tweets and blog posts are also searchable - in fact, if you just say "singpolyma" or link to me in a blog post, there's a huge chance that I'll see it.

    When it comes to factors like immediacy, lifespan,  audience, bandwidth, and sychronity they are all important, but are different for different messages.  If I'm setting up a meeting or working on a project, immediacy and bandwidth are hugely important (thus, face to face or IM are best).  If I'm discussing something of interest to me, asychronity, lifespan, and audience are the most important factors (thus, mailing lists, forums, Pibb, and IRC are best).  There is no "perfect" communication form - all have their place.

    I have requested that people use post/page comments for debugging/feature requests on my projects.  This is because a comment is almost as good as blogging something (it can be used by others who may benefit) and is searchable.  It also reduces the chances that I get asked for the same thing a bunch of times - others can see what is being discussed (which, incidentally, in the same reason I love GetSatisfaction).  Pages + comments are almost as good as (in fact, in many cases, I feel are better than) a wiki.

    Creative Commons Licence © 2006-2008 Stephen Paul Weber. Some Rights Reserved.
  2. Pempeth - Send Messages

    body

    Pempeth is the result of my work based on my previous private messaging TEP.  The protocol draft has matured and there are now implementations! (see the page).  Most notable is a Wordpress plugin, active on this site.

    The development of that plugin also sparked an XRDS plugin, which I have also released (despite its somewhat cryptic interface).

    Those looking at the main page may also have noticed changes. Yes, that's a mini-feed based on my online activity.  Yes, it's a plugin.  The interface, however, only allows for adding sources (not editing or removing) and is somewhat cryptic, so I have not released it yet.

    You can also now log into my blog with your Facebook account (see link in header)!  This uses the API, so I don't got your Facebook password or anything like that.  Also an as-yet-unreleased plugin.

    Fun days!  I'm going to be working at AideRSS as a co-op in the coming months, should be fun and more freeing than school!

    Creative Commons Licence © 2006-2008 Stephen Paul Weber. Some Rights Reserved.
  3. How to Avoid Getting Pranketh'd, Scam'ed, or Phish'ed

    body

    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
    GMail Screenshot [Show Original]

    View Headers in Evolution
    Evolution Screenshot [All Message Headers]

    View Headers in Eudora
    Eudora Screenshot [BlahBlahBlah]

    View Headers in Outlook
    Outlook Screenshot [Options] Outlook Screenshot [Headers]

    View Headers in Outlook Express
    Outlook Express Screenshot [Properties] Outlook Express Screenshot [Headers]

    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.

    Creative Commons 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.

    Creative Commons Licence © 2006-2008 Stephen Paul Weber. Some Rights Reserved.
  4. Replacing SMTP with XMPP

    body

    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 # 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.

    Creative Commons Licence © 2006-2008 Stephen Paul Weber. Some Rights Reserved.
Stephen Paul Weber