Gmail Hashcash Notifications To Your Phone

Gmail Inbox Setup for Hashcash Notifications To Your Phone

If you install my Hashcash for Gmail google script to scan & validate your incoming email according to the presence or absence of hashcash stamps, and you just want notifications for verified emails coming in, you can tweak how the inbox notifies you on your mobile phone. Here's one possible setup:

It's quickest to set this up from the desktop:

1. From the gmail web interface Gear->Settings
2. Inbox tab
3. Inbox type 'Priority'
4. For Inbox sections 1-4, Options->Remove Section
5. Redefine Inbox section 1. Options->More Options...->Show All From Label [#$]
6. Save Changes

Then on your Android phone, configure Gmail:

1. Menu->More->Settings
2. Account Settings->[your email address]
3. -Check Priority Inbox (make default for this account)
4. -Labels to Notify
5.   ->Inbox: off
6.   ->Priority Inbox: off (was: [subtle, always, notify for every msg])
7.   -> [#$]: [subtle, always, notify for every msg]

NOTE: This is a pretty strict set-up in the respect that you won't get notifications for anything that doesn't have a valid Hashcash stamp. Not too useful until most people in your local network also are using Hashcash. That's the problem with network effects.. the usefulness of a thing only becomes apparent once many people are using it together.

If you look into Gmail's Priority inbox rules it's a pretty powerful way to tailor how/when you get notifications.

Tugging at the chains 'twixt myself and The Cloud

[Otherwise, less poetically-entitled: Screw you, NSAGoogle. I'll make my own damn webmail, with blackjack and hookers. Thing is, I actually -want- the webmail too. Really.]

2013-11-18: experiments setting up my own webmail server with IMAP and (eventually) OSS webmail client access

Part I: The MTA and IMAP service (dovecot), plus Thunderbird client access [DONE]
Part II: Webmail client for easy access anywhere (TODO)
Part III: End-to-end encryption using clients in (I) and (II), for anyone (TODO.. and non-trivial, I know)

1. Exim4:
   * just install using debian defaults
   * edit /etc/exim4/update-exim4.conf.conf for your smarthost
     (a smarthost is an SMTP server that will relay mail for you; usually
      smtp.<your_isp> -- note many ISPs these days don't allow any outgoing email
      even from their own customers' IP blocks. Complain bitterly to them that they're
      breaking the internet, not that it will do any good... other than some cathartic anger on your part. Then go find another provider, if you can.)

2. Get an IMAP server:
  apt-get install dovecot-imapd dovecot-sqlite dovecot-pop3d

   * Nice! Top of /etc/dovecot/dovecot.conf:
     "If you're in a hurry, see http://wiki2.dovecot.org/QuickConfiguration"

2.1. Configuring dovecot
  2.1.1 Authentication
   * [Further research here is required. I ended up using the default 'passwd-file'
      accounts rather than 'passwd' account auth which would use PAM to match against
      the system user accounts. It's safer to use 'passwd-file' anyways since that
      means users' email accounts don't have to use their shell accounts.]

  2.1.2 Mailbox setup/privileges
   * My deb system appears to use 'mail' group for /var/mail, so I set
     mail_privileged_group = mail,
     #! mbox_very_dirty_syncs = yes
     #! maildir_very_dirty_syncs = yes
     .. in /etc/dovecot/conf.d/10-mail.conf

  2.1.3 IMAP Compatibility Options
   * Since I like Thunderbird, enable the following IMAP workarounds
     in 20-imap.conf:
     imap_client_workarounds = tb-extra-mailbox-sep tb-lsub-flags

  2.1.4 SSL setup
   * Consider after getting things going, enabling SSL. Generate a self-signed cert
     using Dovecot's doc/mkcert.sh script (see _SSL_ link)
   ** NOTE SSL is required by default, you have to set disabled_plaintext_auth = no
      otherwise!

    i) Go to http://wiki2.dovecot.org/SSL/CertificateCreation
    ii) Download the two files doc/mkcert.sh (or find in the downloaded dist files),
        and doc/dovecot-openssl.cnf
    iii) Edit dovecot-openssl.cnf to match your site install; also edit mkcert.sh
         itself if you want to lengthen/shorten cert expiry and/or the name of the
         generated cert (default: /etc/ssl/private/dovecot.pem)

  2.1.5 IMAP account (server-side): see http://wiki2.dovecot.org/AuthDatabase/Passwd
    Default appears to be 'passwd-file' which sets up a separate username/pass DB for
    IMAP access. One could set up 'driver = passwd' to use the server's local user
    accounts, but that would also grant shell access (usually). Probably a good idea
    if setting up a public server to use the default.

    i) edit /etc/dovecot/conf.d/auth-passwdfile.conf.ext
       Set scheme=SHA512-CRYPT
    ii) $ doveadm pw -s SHA512-CRYPT -u <username>
    iii) cut and paste the resulting string into /etc/dovecot/users
    iv) edit /etc/dovecot/conf.d/10-auth.conf
        auth_mechanisms = plain login  (? Not required apparently)
        (default install only has 'plain')

3. Get a desktop or web-based mail client. I went through a few here:
  x IlohaMail - obsolete, the whole domain is gone, even though it's still a package in
    Debian repos and written in PHP4. So, no docs. Doesn't support POP-over-SSL or other
    encrypted auth schemes due to its age; too bad, it was easy to install. -REJECTED-
  x <lots of other webmail clients, too complicated to get going> -REJECTED-
  x <RoundCube? Still need to evaluate>
  x <MailPile? Looks promising, actively developed but very incomplete. They are working
     on integrated PGP/GPG support, perhaps a post-Snowden emphasis on e2e-crypto? Hope!>
  x .. or a desktop mail client such as Thunderbird.
      Thunderbird Account Settings:
        Server Settings: Server Type: IMAP Mail Server
                         Server Name: <server hostname>
                         User Name: <username> (without @domain.tld)
                         Security Settings: Connection security: SSL/TLS
                         Authentication method: Normal password (?)
        Outgoing Server (SMTP): Description: (your choice)
                                Server Name: <smtp smarthost server hostname>
                                Port: 25 (** NOTE default is 587, won't work!)
        Sec. and Authentication:
                                Connection security: None
                                Authentication method: No authentication

Hello World Blinky for ezSBC2 LPC1347 in Assembler

Doing things the hard way sometimes is the best way to learn. I've been meaning to learn some embedded ARM-fu for years, and just never got around to it since AVRs are just so darn easy (or familiar, in my case).

I like using a simple text editor and command-line toolchain but since most ARM vendors have wrapped up all the details of their chip startup in wizards within their huge IDEs, it's a pain to figure out just what's happening and what is required to bootstrap a given chip.

For my experiment, I chose the LPC1347 microcontroller from NXP, on a simple board called the ezSBC2. This chip has a neat built-in ROM that makes the chip virtually unbrickable -- pull a certain pin on power-up and the chip appears as a USB flash drive, and you just paste in a new 'firmware.bin' file with your code, reset and it's reprogrammed. Couldn't be simpler.

However, it took me two full nights' worth of searching online to find any kind of 'Hello World' reset startup code for the LPC134x chips. The best I could find was some for the related LPC1766, which was close enough for me to eventually figure it out. See below for download. I had to modify the startup.S, main.S and linker script to fit the LPC1347 memory map and peripheral registers.

One thing that isn't spelled out anywhere is that the Cortex-M chips are very different from traditional ARM chips in a lot of ways; for instance, the vector table isn't composed of branch instructions -- it's just a list of absolute addresses, like the old 68000 (and at vector 0x0, just like the 68000, is the initial system stack pointer value). They also don't have nearly as many contexts as traditional ARM (IRQ, FIQ, etc.). I'm still reading up on all the differences but it makes bootstrap code for 'standard' ARM totally inapplicable.

As for NXP-specific differences: not mentioned explicitly on ezSBC's website, but buried in the lpc1347 user manual, is the fact that one must put a 32-bit checksum in the first reserved vector 0x1C to validate the code. Otherwise the USB programmer won't accept the firmware.bin file. I've included a quick and dirty C program in the ZIP file below to patch up the binary after linking.

Hello World Blinky in Assembler for ARM Cortex-M3 NXP lpc1347

ezSBC2 ARM board

NXP lpc13xx User Manual

Resurrecting the OS-9/68K (OSK) kernel using the FAME 68K Emulator

** NOTE ***

I know the code linked here has been broken for some time. Apparently the FAME emu, or (more likely) my abstraction on top of it, does not boot OS-9 properly on x86_64 Windows. I do intend to look into the issue (really!) but have been swamped by 'real life' the last while. I appreciate your patience; please check back periodically to see if I've finally fixed this to work on modern x86_64 Windoze installations and hopefully Linux, where I'm spending more time nowadays. -rlm

The Motorola 68000, sadly, is mostly a relic nowadays. It had a beautiful instruction set and a clean architecture, from software all the way down to the bus protocols. Alas, all good things must pass...

However, there was a damn good operating system written for this CPU which I just can't stand to see die slowly, rotting on lost floppy discs and SCSI drives. The OS of which I speak is the OS-9 RTOS by Microware: a microkernel which was originally written for the Motorola 6809 CPU as a contract from Motorola to showcase their new CPU (most famously used on the Tandy Color Computer, various GIMIX systems, the Sharp X68000 series in Japan, and the Fairlight/CMI synthesizers of the early 80s), then ported to the Motorola 68k series of processors, the x86, ARM and Hitachi SH series, amongst others.

This operating system has been really short-changed by history. Ask most programmers which consumer (non-mainframe/UNIX/'big-iron') system was able to do multitasking and/or timesharing; you'll usually get answers of the Commodore Amiga, or the PC, or the Mac. They're all wrong. OS-9 was doing this in 1979, before the Commodore 64 even existed, with a full-fledged UNIX-style shell environment and all of the flexibility that philosophy brought with it, in less than 64 kilobytes!

The folks at Microware really should be legends in the industry for their forward-thinking software. Applications, device drivers, the kernel, and even instances of devices were all modules using an object-based structure that could be configured at boot time, then subsequently reconfigured at run-time, as modules were added or removed, with no reboots. Hmm, it only took, what, twenty-plus years, for other mainstream desktop operating systems to achieve this (and imperfectly)?

With that in mind, I now place here a small lifeline for this amazing operating system in the hopes it will be preserved (and perhaps improved...)

OS-9/68k 'RUSSBOX' Emulator Proof of Concept

This uses the FAME/68K emulation library under Cygwin to boot an OS-9 68000 'idealized' abstract system of my own design (by 'abstract', I mean a system which doesn't correspond to any 'real' historical system and is as simple as possible for the purpose of booting OS-9).

--
BUILDING AND RUNNING THE RUSSBOX OS-9/68K (TEST EMULATION):

Requirements
--
Windows XP or Win7_x86 (32-bit)
cygwin (32-bit)

From the cygwin prompt in your home directory:

$ git clone git://tripe.blitter.com/os9_68k_sdk_v12.git MWOS
$ cd MWOS
[This gives the pristine MWOS OS-9/68k port dev tree, sans Hawk UI cruft, etc.]
$ git checkout origin/rlm-sys-1
[This switches to a branch which adds the virtual 'RUSSBOX' support files:
  MWOS/OS9/68000/PORTS/RUSSBOX - plus some .d/.a files to support the virtual
  hardware in higher directories within MWOS/...]

$ git submodule add git://tripe.blitter.com/rlm-sys-1.git \
     MWOS/OS9/68000/PORTS/RUSSBOX/rlm-sys-1
[This is the emulator itself, using FAME 68k library]

$ cd OS9/68000/PORTS/RUSSBOX

$ . ./mwos_env.sh

[open a second cygwin terminal]
$ cd MWOS/OS9/68000/PORTS/RUSSBOX/rlm-sys-1/
$ stty -echo -icanon -icrnl -inlcr min 1 && nc -u 127.0.0.1 8800

[return to first cygwin terminal]
./run.sh

[switch to second cygwin terminal]
[press ENTER]
[You should see a RomBug: prompt.]
[Type [.],[ENTER] to see 68k registers]
[Type [g],[ENTER] to start boot]
[After a few seconds you should see the OS-9 '$' prompt.]
[Type some common OS-9 commands, eg 'devs', 'free', 'mdir', 'dir']

NOTES

The backspace/del key doesn't work.. the terminal via UDP is primitive and the exact setup for 'stty' above can probably be improved to at least let through delete properly.

Typing CTRL-C on the OS-9 terminal also terminates the stty connection, rather than transmitting CTRL-C through to the OS-9 target.

** NOTE after typing CTRL-C to interrupt the UDP terminal, one must type blindly:

stty echo

.. to turn on echo for the cygwin shell again.

Eventually I would like to write a dedicated UDP terminal + emulator 'front panel' that can pass all ascii codes through properly, and integrate in other ways with the virtual target (such as some way to show the virtual framebuffer, I/O, etc.)

While rudimentary this serves as a demonstration that the FAME/68k emulation library is sufficiently accurate to fully bootstrap and run the OS-9 68000 kernel and as such we can preserve the OS-9/68k operating system in an environment which will never be subject to the ravages of time, dying hardware etc. :)

rlm-2013-08-22


UPDATE

For posterity and my own records, I am adding below the notes I made years ago on how to backup an RBF (disk) device from an OS-9/68000 machine to a Windows box over serial line via Kermit or ZModem. This was the best solution in my experience for imaging OS-9 disks, with the minor drawback that it requires a working OS-9/68000 box. Linux (and AFAIK Windows/DOS) really don't like 256-byte sector formats, so it's difficult to do from 'the other side'.

---

HOWTO: Transfer OS-9/68k disk images to a remote system

This HOWTO describes the procedure for transferring raw disk images from an
OS-9/68k system to another computer over serial port.

Hardware Required:
1. OS-9/68k target with one functioning serial port
2. Remote system with a terminal program and zmodem capability (I used
   Windows XP and ‘teraterm pro’)

Gathering information

First you must know the format of your OS-9 target’s disks.
[TODO: Quote microware /u0, /d0, /pc0 formats common to many systems]

A utility not included with OS-9 distributions officially, but essential
for managing different disk formats, is ‘dmode’. It can be found on
os9archive.rtsi.com
[http://os9archive.rtsi.com/index.php/os-9-archive-new/file/3913-os-9-archive]


Example for the WCP306:

wcp:dir /hs0

                       	Directory of /hs0 00:13:10
CMDS        	MODS        	OS9Boot     	SYS         	USR
WCP306.readme   init.ramdisk	startup
wcp:dmode /hs0
name=hs0
 drv=0 stp=3 typ=$27 dns=$03 cyl=80 sid=2 vfy=0 (on) sct=32 t0s=32
 sas=8 ilv=2 tfm=0 toffs=0 soffs=0 ssize=256 cntl=$0000 trys=0 lun=0
 wpc=0 rwr=0 park=0 lsnoffs=0 totcyls=80 ctrlrid=0 rates=$30
 scsiopt=$0000 maxcount=65535
wcp:

Transferring the raw disk image

On the OS-9/68k side, the ‘sz’ utility is used to send the output of the
disk’s raw data (using the OS-9 ‘@’ suffix on a device name to indicate raw
mode) via ZMODEM protocol.

Eg., from the OS-9 shell:

$ sz /hs0@
[OS-9 size will wait for connection from remote side]

Then in TeraTerm Pro, choose File->Transfer->ZMODEM->Receive.

The resulting file will be called ‘hs0@’ on the receiving side. That isn’t
ideal, so one can also use OS-9 pipes effectively to give the data stream
a more meaningful name:

$ list /hs0@ >/pipe/wcp306_os9v3.0_disk1of5_hs0.dsk &
$ sz /pipe/wcp306_os9v3.0_disk1of5_hs0.dsk

Or, using kermit in server mode on the OS-9 side and TeraTerm to get files
(bear in mind KERMIT is much slower than ZMODEM):

$ kermit -x -i

Then in TeraTerm, choose File->Transfer->KERMIT->Get...
and enter the raw filename of the disk (eg., /hs0@)

Here again, one would have to rename the downloaded file to something
meaningful before transferring another disk so as not to overwrite the last
transferred image.

One could also use the stock OS-9 ‘copy’ command with named pipes and tar to
send over serial, then use untar on the other end, or similar methods, to
transfer raw disk images. But ZMODEM has error correction, which is desirable
since serial comms can have errors that would otherwise go undetected.

To do a file-level (rather than sector level) copy of a disk device, one
could use tar on both ends to transfer the disk’s contents:

[From OS-9 side]
$ gtar cf /pipe/hs0.tar /hs0 #128k &
$ sz /pipe/hs0.tar

[On PC side, using TeraTerm Pro]
File->Transfer->ZMODEM->Receive

---

Hashcash for Gmail

For more information about Hashcash, please see http://www.hashcash.org/

For issues see here.

Privacy Policy: This app uses GMail App APIs to access to your gmail inbox, to tag, filter and re-file emails. It does not store or save any personal information, nor send any info to external sources.

Terms of Service: This app offers NO WARRANTY or GUARANTEE OF FITNESS. USE AT OWN RISK. The author assumes NO responsibility for any effects, intentional or otherwise, on contents of your gmail inbox.

This page is for information on my experimental HashCash for GMail -- a combination of a Chrome extension (or google gadget plugin for gmail, blogspot or any other OAuth gadget hosting page) that generates Hashcash stamps for inclusion into emails you send. For maximum usefulness it should be paired with my nearly-ready google app script (which will also be published as a Chrome App) that scans incoming gmail messages and flags them accordingly by detecting these stamps.

The solution consists of two parts:

• The Hashcash Mint Chrome extension/google-gadget, which lets one generate a valid hashcash stamp from within the gmail web interface or from anywhere while running Chrome; and
• The Hashcash for Gmail google app script, which runs periodically on your gmail inbox to scan for valid hashcash stamps and flag the emails accordingly.

Some readers may say: 'Doesn't gmail do an awesome job of detecting spam already? I used to think so, but their filters really started breaking down for me a few months ago. If someone can explain why that may be occurring, I'd appreciate an explanation. I'm sick of spam.

1. Installing the Hashcash Mint Google Gadget

1a. For Non-Chrome Browsers [Firefox etc.]

• Enable 'Labs' in your gmail account (Gear icon->Settings->Labs) if it isn't already;
• Enable the 'Add any gadget by URL' feature;
• Add the Hashcash Mint gadget (url: http://www.blitter.com/~russtopia/googlegadgets/hcgen.xml)

You may have to reload gmail to see the gadget appear in your sidebar on the left. Google talk may mask the google gadgets area; in that case click on the ellipsis button at bottom left to switch to google gadget view.

1b. For Chrome Browsers

• Just click here to install the extension.

After clicking 'Mint' and the Hashcash stamp has been generated, you just hit CTRL-V in an email while composing to paste the just-generated stamp (the extension has the 'copy-to-clipboard' permission so it should do the 'copy' CTRL-C for you.)

2. Installing the Hashcash for Gmail App Script

2a. For Non-Chrome Browsers [Firefox etc.]
 

• Visit this link and approve the app script.

 You likely require a Google account for this, but since this is intended for gmail you already have that, right? :)

2b. For Chrome users: Installing the Hashcash for Gmail App

• Just click here to install the Chrome app.

Hashcash is an idea that really should have taken off by now.. but email servers and clients have never seemed willing to agree to implement it, which is a shame as it really could make spam nearly disappear -- if enough people would just use it!

So I hope to make this as easy to use as possible -- if you like it, please tell those you know to try using it too. If you're someone who knows how to write Outlook, Thunderbird or other email plugins, consider writing an equivalent to my Hashcash for Gmail inbox scanner for those mail hosts, so others can easily start using Hashcash!

Hashcash for Gmail -Support & Issues

Version 4 [2013-11-27]:

Issue

There appears to be a bug in the auto-registration of the timed trigger in the mail scanner. The trigger is supposed to run once a minute to scan for incoming mail with hashcash stamps.

Solution

• Open chrome://apps and click on the "Hashcash for Gmail" icon;
• Click on the "Disable" button which should change to "Enable";
• Click on "Enable" again and it should change to "Disable"
• Close the app.

The per-minute trigger should now be active and emails recently placed in your Inbox will be scanned and tagged accordingly.