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.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- RSS Feeds
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
3 min 7 sec ago
- Reply to comment | Linux Journal
25 min 26 sec ago
- Android has been dominating
29 min 58 sec ago
- It is quiet helping
3 hours 15 min ago
3 hours 32 min ago
- Reachli - Amplifying your
4 hours 49 min ago
5 hours 37 min ago
- good point!
5 hours 40 min ago
- Varnish works!
5 hours 49 min ago
- Reply to comment | Linux Journal
6 hours 19 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?