MojoMailMan – The Mail Must Go Through (painlessly!)

MojoMailManOne of the areas we are exploring via our COWMesh project is enabling service specific access based on connectivity in rural and urban low income communities. This is one of the reasons that we found ourselves unable beyond a point to support the demands of the NetNeutrality debate that recently took over Indian cyberspace.

The smartphone and connectivity environment in India, particularly in remote and rural areas is such that even if Net Neutrality was enforced, certain content would overtake others in terms of access. As a result, in our opinion any connectivity channel is worthwhile to utilize with the proviso that a parallel effort is in place with the community to enable information and content sharing across channels.

To this end one experiment we are working on is enabling reliable email access in remote areas where only spotty 2G coverage is available, in a manner that is painless for the user, with the intention of enabling more adoption of email as a communication tool in these areas.

The mechanism we’re working with is fairly simple. The local community sets up a local wireless network that includes some of the points where connectivity is available. At the points where connectivity is available we set up email servers that also act as clients. The server is configured with the email accounts of all email users in the wireless operating community. The server connects to the Internet via a mobile connection (tethered smartphone or dongle) and downloads everyones emails.

Everyone then goes to the local server and logs in to read and respond to their email.

The result is that people do not have to deal with slow loading of heavy interfaces or put up with unwanted ads just to read email. They interact with a fast local server that responds instantly at LAN speeds and later processes the email as and when connectivity is available.

To set this up we used

  1. Postfix – a Mail Transfer Agent (MTA) to send email through another server using it as a mail relay system
  2. OfflineIMAP – a tool that allows a user to synchronize online and offline IMAP accounts, to download mail
  3. Dovecot – to run a local IMAP and POP server that users can connect to, to expose a joint interface to Postfix and OfflineIMAP and also provide synchronization between local and remote authentication
  4. Roundcube – a webmail client to provide an interface between Dovecot and the end users.


We set these up on a RaspberryPi (3) running Raspbian Jessie. Some of the current assumptions we are working with –

  1. One linux user on the Pi per email user on the server – need to see if this scales
  2. User community is cohesive enough and new enough to email to be willing to put their passwords in text files on a common machine. This will need to change if and when the model scales to be able to allow users to alter their passwords without the need for the administrator to know the password. This is also part of the general discussion on roles of systems administrators in community owned and operated networks.
  3. Increasingly strong 2G signal at at least one point which can be linked to the larger inhabited area via a point to point or mesh based WiFi link (that is not the subject of this article)


Given that the above assumptions are met, here is the configuration we used for the server itself


Postfix was installed by running the following –

sudo apt-get install postfix

We are only using postfix to send mail through users external mail accounts so the only thing we need to do is tell postfix where to look for the username and password required to send mail through users accounts. This is done by adding the following lines to the end of /etc/postfix/


smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtp_tls_CApath = /etc/pki/tls/certs


The first option smtp_sender_dependent_authentication sets up Postfix to use credentials for external email servers based on the sender’s “From” field. This means that whatever mail client is used by the end user should be able to provide the users external email id as the From field while sending email. This will become relevant while configuring Roundcube later.

The sender_dependent_relayhost_maps option tells Postfix to select the external mail server to use to relay the email based on the From field as well.

smtp_sasl_auth_enable tells Postfix to turn on authetication for SMTP.

smtp_sasl_security_options disables anonymous sending of email.

smtp_sasl_password_maps tells Postfix where to look for credentials for different email IDs.

smtp_tls_policy_maps tells Postfix where to check whether or not to use Transport Layer Security for a connection with a particular email server.

smtp_use_tls sets the default policy for SMTP TLS to on.

smtp_tls_CApath tells Postfix where to find certificates for Certifying Authorities.

smtp_tls_note_starttls_offer seems to tell Postfix to note when a TLS offer was made, but I’m not entirely sure what this does (anyone who knows, please add in the comments)

After editing /etc/postfix/, we next create all the “maps” defined above.

First create /etc/postfix/sender_relay and add the following lines (one for each sender address)

<senderemailaddress> [<smtp server address>]:<portnumber>

e.g. if your email is and exposes an SMTP service at on port 587. your entry would look like – []:587

Next we create the file we referred to above in the smtp_sasl_password_maps option i.e.


and add the following lines to it – <usernameforuser1>:<passwordforuser1> <usernameforuser2>:<passwordforuser2>

<one for each external email account to be used>

Finally we create the file specified in the smtp_tls_policy_maps i.e.  /etc/postfix/tls_policy and add the following line (one for each external mail server  –

<server address>:<port number> encrypt

e.g. in the for the server above if you wish to enable TLS the line would read – encrypt


After this we create the hashes of these files that Postfix will actually use by running the following commands –

sudo postmap /etc/postfix/sender_relay
sudo postmap /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/tls_policy



We installed OfflineIMAP by running

sudo apt-get install offlineimap

At this point we have to set up each users email account (Note: this should be replaced by a web based admin package, possibly vimbadmin or postfixadmin).

In each users home directory, edit the file .offlineimaprc and add one local and one remote repository as below for each email address that the user wants to access mail from.


accounts = GMail, OtherGMail

[Account GMail]
localrepository = GMailLocal
remoterepository = GMailRemote
autorefresh = 2

[Repository GMailLocal]
type = Maildir
localfolders = ~/Maildir/Gmail

[Repository GMailRemote]
type = Gmail
realdelete = no
remoteuser =
remotepass = password1

[Account OtherGMail]
localrepository = OtherGmailLocal
remoterepository = OtherGmailRemote

[Repository OtherGmailLocal]
type = Maildir
localfolders = ~/Maildir/OtherGmail

[Repository OtherGmailRemote]
type = Gmail
realdelete = no
remoteuser =
remotepass = password2

The options above are described below :

accounts : Lists all the accounts associated with the user, separated by commas

type: Type of account, IMAP/Gmail/other

remoteuser/remotepass: Username and password for the remote repository

realdelete : Tells OfflineIMAP whether to delete messages from the server when they are deleted from the local repo


To test if the configuration is working, run:




Now that we have both sending and receiving configured, we will configure Dovecot to manage access to them by a webmail client as well as authentication

To configure Dovecot first we enable the appropriate protocols by editing /etc/dovecot/dovecot.conf and setting the protocol option

protocols = imap pop3 lmtp

Next we edit /etc/dovecot/conf.d/10-auth.conf to tell Dovecot how to authenticate users. To do this ensure that the line #!include auth-system.conf.ext is uncommented.

Finally we tell Dovecot where to find email for each user by setting the mail_location option in /etc/dovecot/conf.d/10-mail.conf

Configure the appropriate inbox by setting the namespace (this is relevant for multiple addresses and needs further explanation)

mail_location = maildir:~/Maildir/:INBOX=~/Maildir/Gmail/INBOX:LAYOUT=fs
namespace inbox {
  separator = /
  location =maildir:~/Maildir/Gmail/:INBOX=~/Maildir/Gmail/INBOX:LAYOUT=fs
  inbox = yes
  list = yes
  subscriptions = yes



Lastly we need an interface or what is known as a Mail User Agent or MUA to act as a client to Dovecot and allow users to access their email.

To do this we used Roundcube, a webmail client that is also installed on the server. Of course, individual users are free to use other clients as they wish, but the Roundcube interface provides a web based one.

To install Roundcube we ran –

sudo apt-get install roundcube

To configure edit /etc/roundcube/ and set the following options

// The mail host chosen to perform the log-in.

$rcmail_config['default_host'] = 'localhost';

// TCP port used for IMAP connections

$rcmail_config['default_port'] = 143;

// IMAP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or null to use
// best server supported one)
$rcmail_config['imap_auth_type'] = null;

// If you know your imap's folder delimiter, you can specify it here.
// Otherwise it will be determined automatically
$rcmail_config['imap_delimiter'] = null;

// SMTP server host (for sending mails)

$rcmail_config['smtp_server'] = 'localhost';

// SMTP port (default is 25; use 587 for STARTTLS or 465 for the
// deprecated SSL over SMTP (aka SMTPS))
$rcmail_config['smtp_port'] = 25;
// SMTP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or empty to use
// best server supported one)
$rcmail_config['smtp_auth_type'] = '';

Having set these, we restart all services and once they are back up, users can log in and access their email for both sending and receiving by going to


and logging in as the linux user they have been assigned. After logging into Roundcube, each user will have to add one identity each for each of the mail addresses that they wish to send email from by going to the Identies section under settings and filling in the form.

Screenshot from 2016-05-03 21:06:47







References –


PiFiTV – Combining New Media Models

Wi-Fi Mesh

Wi-Fi, (802.11b/g) is a dStarTopologyeregulated medium in most countries. Most internet users are familiar with Wi-Fi networks and most mobile devices today come equipped with an inbuilt Wi-Fi adapter. Typically Wi-Fi is set up in a hub-and-spoke configuration, where one Wi-Fi hub provides connectivity to many clients. The hub acts as a gateway to process all traffic on the network and in order to communicate with peers on the network a user must go through the gateway. This is analogous to the service provider model of communications and Wi-Fi has a strong use case as a means to share a single internet connection between multiple users.

While Wi-Fi has predominantly been used as a means of last mile connectivity to service providers, most Wi-Fi enabled devices can also be used in peer to peer mode, i.e. to communicate directly with other devices, without the intervention of a service provider or gateway. This ability can be used to build a peer to peer based network topology called a mesh. A mesh network is different from a hub-and-spoke network in that there can be many paths between two points on the network. As a result, members of a mesh network share a peer or peer-like relationship.Mesh
The Internet itself is a mesh of meshes as it does not depend on any single service provider and service providers become peers from the point of view of the internet. Reducing costs of Wi-Fi equipment and new developments in networking software have made it possible to build low cost, community owned and operated mesh networks and lately this form of network is becoming a popular alternative to the cloud, particularly for low income and rural communities Multiple meshes can be connected to each other and to the internet in innovative ways such as physical transfer of bulk data (Data Muling) and by pooling low bandwidth connections available on the mesh.


The RaspberryPi is a USD35 single board computer. The Pi comes with 512 MB of RAM and a 1GHz processor, making it comparable in performance to a netbook or a cheap desktop computer.
The Pi is more than adequate forPiImage

  • Basic web browsing
  • Multimedia Access
  • Basic Knowledge processing tasks

The Pi can use an HDMI or S-Video interface for a display, meaning that it can even be connected to old CRT based TV sets, which are quite popular in rural and urban low income households. With a USB Wi-Fi adapter and a keyboard, the Pi can convert any TV into a PiFiTV

Components and interactions on the PiFiTV network

The following components and interactions are possible in a community owned wireless mesh scenario











PiFiTV Features

The PiFiTV model holds the possibility of putting even rural and low income user groups at par with users of high end interactive television. PiFiTV can use even basic CRT based television sets over the S-Video channel besides supporting newer high definition TVs via HDMI. Moreover, the RaspberryPi is a low power device (5V, 1A) and can even be powered with a cheap solar panel, adding almost no extra cost to the household’s power budget. The addition of a simple wireless mouse makes the Pi a two way interaction device, where users can not only select the program they want to watch but also interact with it if the content is so designed. With a battery operated speaker, can be used as a Wi-Fi radio during power cuts. We are currently exploring the feasibility of using low power display devices such as pico projectors as well. From a provider standpoint, the PiFiTV model is similar to the local cable operator model recently phased out by digital cable, combined with the possibility of multiple content providers on the same network. This means significantly lower content hosting and dissemination costs for providers since the underlying network is relatively small scale, community owned and entails a lower over-all cost of operation. In fact any provider can join the network as a peer and host content by simply operating or sponsoring the operation of some member devices.


We are very keen to partner with content providers such as independent artists, writers, bloggers, performers and other interested parties who are keen to acquire a user segment in areas beyond the pale of connectivity Partners are welcome to engage with us by

  • Wholly or partly supporting community Wi-Fi network build outs in low/no connectivity areas
  • Providing content for delivery on Wi-Fi networks that we are already setting up through one of our existing partners
  • Visiting the deployment zone and conducting agenda/content specific workshops that have a clear follow on the network
  • We are also open to other interesting ideas for collaboration

Proof of Concept

We are working on a project in collaboration with Janastu हैकरgram to build and test a Community Owned Wi-Fi mesh network connecting 5 villages in the Devarayanadurga area in Karnataka. The project is called COWDev and is supported by the Open Technology Fund. The region is interesting as it has a large underserved population in terms of connectivity, owing to its position inside a forest reserve where getting permissions to set up cell phone towers is hard. We are keen to focus on women and young people as primary users and operators of this network PiFiTV is one of the key services we will be piloting on this network.

The initial PiFiTV demo system is set up at the residence of Renu and Mukunda Rao ji of Janastu, who have been living among the community in Hale Kote (one of the villages in the region) for a number of years. Janastu is the host organization and community connect partner for हैकरgram at Hale Kote.