Radio E-mail in West Africa: The Complete Version
Sometime sooner than later, users in Kissidougou will want to try sending their own messages to others. If you have followed along with qmail this far, you may already have some ideas for getting mail back out from the field to any address on the internet. But it turns out there are a couple of tricky parts in sending e-mail from Kissidougou to other refugee.ngo users outside of Kissidougou, whether in Conakry or another field office. Figure 3. considers the case of sending a message from Kissidougou to a user in Conakry, addressed to firstname.lastname@example.org.
In Kissidougou as in Conakry, we want to keep the convention of addressing mail to users with email@example.com, no matter where the recipient is actually assigned. This means that refugee.ngo also must be listed in the locals control file on kenya, so qmail will accept and deliver mail originating on the local network in Kissi and addressed to recipients posted there. This avoids the delay and extra traffic of an unnecessary round trip to the mailhub in Conakry.
The question, then, is how to forward mail addressed to users at refugee.ngo, but who are not found locally. The first part of the solution is to set up fastforward in pass through mode by using the -p switch. With this option, if a user isn't found in the /etc/aliases database on kenya, fastforward exits 0, allowing the message to be processed by further instructions in the alias .qmail-default file.
Which brings us to the second part of the solution. As shown in the diagram, the second line in this file
uses qmail's forward utility to send any message to a refugee.ngo addressee not found locally, rewriting the domain part of the address as mailhub.refugee.ngo. In our example, the envelope address is rewritten as firstname.lastname@example.org and returns to qmail further processing.
Again qmail checks the locals control file, and this time finds no entry for mailhub.refugee.ngo. But now there is a matching entry in the virtualdomains control file. This particular entry, with the first field empty, is a form of qmail wildcard expression and has the effect of treating any domain as a virtual domain. In this case the entry
tells qmail to forward all messages for any domain to the user qrelay, prepending the string qrelay-ppp- to the original address. Now our outbound message will be addressed to email@example.com. (And any other internet-bound addresses would be rewritten likewise, such as firstname.lastname@example.org.)
Similar to the user qturn on the radiohub congo, qrelay is a special user account we set up on all field hosts, such as kenya, to receive all mail destined for outgoing delivery via HF radio modem. The qrelay user has a home directory of /var/qmail/qrelay, and the dot-qmail instructions in its ~/.qmail-ppp tell qmail to deliver to the Maildir mailbox ./.QMAIL.PPP/. Here the messages for all outbound mail will collect until our next PPP link over the radio. Then we will again use QMTP and serialmail, this time in the other direction.
When the link is up, the command sequence that sends the batch of collected mail to the radiohub in Conakry is:
# cd /var/qmail/qrelay # maildirqmtp .QMAIL.PPP qrelay-ppp- 10.0.10.241
As in the previous example, the first argument to maildirqmtp is the path to the Maildir directory containing all outgoing mail. The third argument is the IP address assigned to the radiohub end of the PPP connection. And the second argument is the prepended string to remove from each envelope address. Now when maildirqmtp sends the example message, it will be restored to email@example.com. (And any e-mail to guinix would be restored to firstname.lastname@example.org.)
Bounding wirelessly out of Kissi, following rainbows and hot harmattans, the message gracefully traverses the wilds and dangers of earthly terrain to arrive safely in Conakry on the radiohub congo. And here it won't linger. When qmail doesn't find any matching entry in the locals control file, it immediately queues the message for remote delivery. The entry in the smtproutes control file then has the wildcard effect of relaying the messages destined for any domain back to the mailhub server. This configuration purposely segregates the radiohub host as a server only for HF links, while using the mailhub host for all other e-mail services and administration.
When qmail receives the message on coyah, it now finds an entry in the locals control file for mailhub.refugee.ngo and initiates local delivery. In what by now should be a familiar sequence, fastforward matches lois.lion in the /etc/aliases database and passes the message for delivery to the llion user account. The message is then delivered to llion's POP3 mailbox, the Maildir named ./.QMAIL.POP/. Hungry for word from Ms. Rabbit in the field, Ms. Lion pounces on her mouse—and lo the message is deposited right to her own desktop.
What if lois.lion is reassigned to the field office in Nzerekore? The administrator would make the change in mailhub's /etc/aliases file and run the fastforward version of the newaliases command to update the fastforward database. Now qmail will turn messages for lois.lane around for delivery to email@example.com via HF radio, as in the rhonda.rabbit example. In this way Conakry serves as the central hub for all e-mail traffic, and field offices need never make links with one another directly.
|Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform||Jan 23, 2015|
|Designing with Linux||Jan 22, 2015|
|Wondershaper—QOS in a Pinch||Jan 21, 2015|
|Ideal Backups with zbackup||Jan 19, 2015|
|Non-Linux FOSS: Animation Made Easy||Jan 14, 2015|
|Internet of Things Blows Away CES, and it May Be Hunting for YOU Next||Jan 12, 2015|
- Designing with Linux
- Wondershaper—QOS in a Pinch
- Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform
- Ideal Backups with zbackup
- Internet of Things Blows Away CES, and it May Be Hunting for YOU Next
- Slow System? iotop Is Your Friend
- New Products
- Non-Linux FOSS: Animation Made Easy
- diff -u: What's New in Kernel Development
- Hats Off to Mozilla
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane