Related Topics:
 • NOS TCP/IP
 


 Popping Mail from JNOS


Moving User Mail from Jnos to your Linux OS...

W

hen people hear the word mail and the name JNOS used in the same sentence, they often shudder! Mail can be very challenging, even daunting at times, especially if you are configuring the rewrite file, a dedicated listing of rulesets that re-directs mail from within the JNOS application.

So I am not going to address the rewrite file here, as capable as it is, but rather, persuade you to employ the Linux OS to handle mail on your system. Not necessarily simple, but a bit more straightforward than struggling with the rewrite file. If you regard yourself as a casual user, and are not forwarding network "traffic," then you can postpone the mastery of the rulesets in the rewrite file, and just enjoy mail as a user!

If you have been working with Linux for a while, then you probably already know something about how to use mail on your machine. If you are new to the Linux mail system, you should not have too much difficulty learning the basics. Of course, we need to go a little beyond the basics here to extract mail from JNOS and deliver it to Linux. We will not discuss sendmail here, that is a huge topic. However, we will touch on procmail and fetchmail in an elemental form.

There are, at least, two ways to move mail across systems. One is to enter the mail client program and "push" or forward the mail to the new address; the other is to use fetchmail to "pop" the mailserver and have the mail delivered to you just as an ISP does. Is one any better than the other? Is logging into JNOS and forwarding an email to the host machine, or some other network machine, any better than popping the JNOS mailserver? Each probably has its own advantages. We will be examining fetchmail (POP) as an alternative conveyance to the "push" method ...




Constructing the Mail "Routes" between JNOS and Linux

Our Mission

Our mission is to pop the JNOS mailserver into a Linux account(s), probably the root account. As an option, we might want to sort that incoming mail into special mailboxes which identify the senders, or where that mail came from, such as a person or an organization. These techniques could be extented to pop any mailserver, but for now, we are just going to explore popping the JNOS mailserver...

A Few Preliminaries...

Almost all Linux distributions come with procmail built into them, but you need to be sure! Change to the /etc directory using cd /etc. Once there, issue this command:

    grep procmail sendmail.cf

You should see a line similar to this:
     Mlocal,     P=/usr/bin/procmail, F=i@lsDFMAw5b:/|@qShP, S=10/30, R=20/40
                 A=procmail -a $h -d $u
Don't worry about what all this means. If it is there, then you have procmail on your machine. As a further test, you can do whereis procmail. It should come back with:
     /usr/bin/procmail
Procmail is a program that moves mail files from /var/spool/mail, the central repository for all incoming mail via sendmail, to mailboxes that are defined in the .procmailrc control file. If there are no "instructions" in the .procmailrc file, the mail remains in /var/spool/mail/some_user to be picked up when that user logs in. If you have a group of senders who mail you "letters," then using the .procmailrc file, you may create mailboxes in your /root or /home account, one for each sender, and all the incoming mail will be sorted for you! A nice feature if you get alot of mail! (You can even use the .procmailrc file in the battle against spam.) Procmail is a very powerful program, often under-utilized on Linux systems, even by the pros!

Now we need to check on fetchmail. So issue this whereis fetchmail command and you should see:
     /usr/bin/fetchmail
And, it also has an accompanying control file named .fetchmailrc. This file may or may not exist. Some install programs will give you a very basic .fetchmailrc file. But usually, it does not exist unless you configure it.

If you have all these "pieces" of the puzzle, then you can pop just about any mailserver that you can reach, including the one on JNOS and that is the one we are after!

NOTE : Recall that smtp mail needs IP routing! So be sure that all your routes are configured properly. If you are moving mail on the same host machine, between the JNOS application and the Linux OS, you might want to review the set up for the SLIP line and its interface sl0 again. If you are working over a LAN (Local Area Network), be sure that you can ping your JNOS application from each machine that you expect to move mail to, coming from the JNOS mailserver.

Setting up the Popusers File for JNOS

In order to pop the mailserver in JNOS, permission has to be given! Not just anyone can issue this pop! You as the system administrator have to decide whom you are going to allow into the server. You naturally would allow yourself, and perhaps a few other "trusted" operators who are assistant admins. To enable this, you must create a file, as the user root, called popusers.

Make sure you are in the account /jnos. Then using a text editor, I use vi, enter the username, followed by a colon (:), and the password for that user also followed by another colon (:). That is correct, two colons! Here are the contents of my /jnos/popusers file:

    ka1fsb:karl:
    sysop:passwd:
As you can see, this is a very simple file. I have included myself as a regular user and myself as the sysop with a "bogus" password named passwd. (You need to use your real password for the JNOS sysop account.) Each additional user would be placed on its own line. To list out the file, issue ls -l popusers. You should see a line like this:
     -rw-------   1 root     root           24 April 17 11:17 popusers
Note that root owns this file and grants read/write permissions to only root for security reasons. If you include sysop in this file, you must be sure to restrict access! (The commands, to remove any "group" reads or "other" reads, are chmod g-r popusers and chmod o-r popusers, "g" for group and "o" for other, respectively.)

When you have populated this file, and are happy with the security levels, the set up for the JNOS side is done!

Configuring the .fetchmailrc File for Linux

Now it's time to configure the .fetchmailrc control file on the Linux side. When you run the program fetchmail, the first event is the scanning of the command line to pass any specified parameters. However, if you configure the .fetchmailrc file, the program will read that, as well as the command line arguments, for its operational parameters. Here is a sample /root/.fetchmailrc file:

     # Set up commands for fetchmail
     # 04-17-04
     # KA1FSB/kbn
     # --------------------------------------------------------------
     # For the JNOS machine, authentication file there is popusers
     # --------------------------------------------------------------
     defaults protocol pop3
     poll 44.56.26.11
             user ka1fsb there with password karl to root here
             user sysop there with password ****** to root here

     # NOTE: The asterisks need to be replaced by your real sysop password
Let's take a closer look at this file. Any line with a leading hash mark is a comment and not seen by fetchmail. The first instruction line lists some general purpose parameters, the protocol to use for example, pop3. This line may have many more "defaults" specified, but to keep it really simple, only the protocol type is configured here. The "poll" instruction is aimed at the mailserver machine. It can be a Fully Qualified Domain Name. If it is, then you need to be sure you have a DNS (Domain Name Server) within easy access, either via the resolv.conf file and your ISP connection, or a local DNS on your network. By using the IP (number) address, you avoid any problems with name resolutions. Use this to start. If you want to change to a domain name later on, that's fine too, just be sure to test it.

The last lines here are the real "workhorse" commands. Notice that you may use "filler" or "noise words" to gain some clarity. For example, this line effectively says, "move mail from the account ka1fsb with a password of karl on the 44.56.26.11 machine to the root account here on this machine." And, much the same for the sysop's line...

A crucial step for this file is to be sure that ONLY root has permissions to read! Otherwise, untrusted users might be able to read this file for passwords! Not, "A good thing!" (To inversely quote a notorious TV daytime hostess :)

After configuring this file in vi, or some other text editor, set your permissions so that root has read and write permissions only. To verify, issue this command: ls -al .fetchmailrc. You should see this line:
     -rw------   1 root     root           504 Apr 21 16:10 .fetchmailrc

Remember that this .fetchmailrc file lives in the root directory, that is /root. You could also make one for any other user on your system and locate it in the /home/some_user account. Just be sure it is that user who owns and has the rights to that file. Then, when that user logs in, they could pop for mail from the JNOS machine and it would "land" in the /var/spool/mail/some_user account/directory.

If that "some_user" were ka1fsb, then an ls -al .fetchmailrc command would display this line in the account for ka1fsb on Linux:
     -rw------  1 ka1fsb   users          573 May 1 10:53 .fetchmailrc
If you created the file here, the owner would be ka1fsb. The group should be "users." If not, use chgrp users .fetchmailrc to change it... Now, assuming the .fetchmailrc file above (minus the sysop line), a fetchmail from this login account will pop the JNOS mailserver for any mail for ka1fsb residing there, and it will be delivered to this login account on Linux as evidenced by both the fetchmail status line return and the mail command if required.

The Actual Fetch

Once all these files have been built and installed, the actual fetch is quite easy. Here is a nice command that simply tells you if you have anything to fetch: fetchmail -c. It will return with either a count or a message saying there is no mail to fetch.

Issuing the fetchmail command by itself will make a connection to the server and deliver the mail according to the instructions in the .fetchmailrc file. You may now enter the mail command from your login directory and you will see the mail delivered to your account space in /var/spool/mail/root. The mail on the JNOS side will be flushed, that is, it will no longer reside in the JNOS mail space! However, you may invoke fetchmail with the "-k" switch and the mail will be deliverd to you and remain on the JNOS mailserver! (See man fetchmail for more details ...)

You may also wish to keep several .fetchmailrc files, under various names, in a special directory, perhaps fetchmailrcs, and copy them into the real .fetchmailrc file as needed. Or you could place all the commands in one big file and let them fail gracefully if they don't find mail on the server polling lists.

Testing the System

It's always a good idea to run a few simple tests to verify that all is well! The easiest approach is to login to JNOS as yourself, or as the sysop. Then write yourself a message, using sp "your_call_sign". Enter "test, test, test" for the text body, or whatever identifies this note for you.

Now from the Linux side, either from your root account or from a "parallel" account (your callsign as a user login on both JNOS and Linux), do fetchmail -c and see what comes back. It should indicate that there is mail waiting to be popped in your account. Make sure that the .fetchmailrc file is "syncronized" with the accounts in question. So, if you logged into Linux as root, and you want to pop a JNOS user account, then your .fetchmailrc file would be similar to the one listed above with root as the recipient.

If you logged in as a user on Linux using a callsign, for example, then replace root with that "user" callsign.

             user ka1fsb there with password karl to ka1fsb here
where ka1fsb is a user login on Linux too.

The following excerpted sessions illustrate the test procedure...
ka1fsb:~# telnet 44.56.26.11
Trying 44.56.26.11...
Connected to 44.56.26.11
Escape character is '^]'
JNOS (ka1fsb-3.ampr.org)
login: ka1fsb
Password [408bbf92] : ******* 

[JNOS-1.11f-BFHIM$]
Welcome Karl,
to the ka1fsb-3.ampr.org TCP/IP Mailbox (JNOS 1.11f (Linux))
Currently 1 user

MOTD: Karl, Wellesley MA, 10 miles West of Boston: FN42jh
      NOTE: "O" is disabled, use "CONV" or "TALK" to chat!
      "Events" lists today's AX25 connections log...

You have 0 messages
WELLS:KA1FSB-7 Area: ka1fsb Current msg# 0
NEWS,SOLAR,LNXNODE,TALK,MOTD,HFDB,EVENTS,WHOIS,HOSTS,DIP,?,A,B,C,CONV,D,E,F,
H,I,IH,IP,J,K,L,M,N,NR,O,P,PI,Q,R,S,T,U,V,W,X,Z >
sp sysop

Subject:
Hello Sysop
Enter message.  End with /EX or ^Z in first column (^A aborts):
This is a test for sysop
/ex
Send(N=no)?

Msg queued
Now I will log back in as the sysop and list my mail, lm
Welcome sysop,
to the ka1fsb-3.ampr.org TCP/IP Mailbox (JNOS 1.11f (Linux))
Currently 1 user

You have 1 message  -  1 new

Mail area: sysop
1 message  -  1 new

St.  #  TO            FROM     DATE   SIZE SUBJECT
> N   1 sysop         ka1fsb   Apr 25  372 Hello Sysop                        
WELLS:KA1FSB-7 Area: sysop Current msg# 1.
Now here is the result of the fetchmail -c command from Linux.
     fetchmail: 1 message at sysop@44.56.26.11
And, here is the result of the fetchmail command from Linux and the actual pop on/from JNOS.
     fetchmail: 1 message at sysop@44.56.26.11
     reading message 1 (72 bytes) flushed
Another login to JNOS as sysop will show that the mail for sysop no longer resides there, but has in fact been flushed and moved out, and is now on the Linux machine that did the fetch/pop in the /var/spool/mail/root account. (Or, if procmail is in force, wherever it was instructed to deliver it...)

Here is the final status of the mail as it resides on my /root/Mail/ka1fsb account. (Note: My procmail delivered it to my ka1fsb "sender" mailbox.) The X-BBS-Msg-Type identifies this as "P"ersonal mail orginating from the JNOS BBS system. (It could have been a "B"ulletin as well...)
     Message 21:
     From ka1fsb@ka1fsb-3.ampr.org  Sun Apr 25 10:07:13 2004
     Date: Sun, 25 Apr 200409:39:43 EDT
     From: "Karl B. Norton" 
     To: sysop@44.56.26.11
     Subject: Hello Sysop
     X-BBS-Msg-Type: P

     This is a test for sysop
The mail has now been transferred successfully from the JNOS mailserver to one of my accounts on Linux! (Whew!)

... Going the Other Way...

What if you wanted to pop the Linux Host mailserver from JNOS? Can you do that? And, the answer is yes! If you can fetch from JNOS to Linux, you should be able to "fetch" from Linux into JNOS. (Note: Some packages, and their setups, may restrict this access.) The facility in JNOS is called popmail.

The syntax to configure and start up the client daemon from the JNOS admin console, or the autoexec.nos file, is:

  • popmail addserver host [pop_timer] [pop_window] protocol mailbox username password


Where the host is the FQDN (domain name) or an IP number, the optional pop_timer is the frequency of popping in seconds, the protocol would normally be pop3, the mailbox is the account/login user name on Linux, the username is the Linux account login name, and the password is the login password for that account. (There is also a "pop_window" hh:mm-hh:mm option which only allows pops within that time frame.)

Here is a sample command from my autoexec.nos file:
     popmail addserver 44.56.26.10 pop3 ka1fsb ka1fsb some_password
To see if the popmail client has been "activated," issue this command:

  • popmail list


And you should see this line coming back on the JNOS console.
     44.56.26.10              (0/0) POP3 ka1fsb
This indicates that you are ready to pop! Note further that you will need a separate command line for each user that co-exists between JNOS and Linux.

Since no time parameters were specified above, to actually do the pop, issue this command from the JNOS admin console (You need to be the sysop to do this...):

  • popmail kick 44.56.26.10


Mail for all the users on that host machine, who have been sited in the popmail command(s) as specified above, will be moved over to the JNOS accounts, each user in their respective mailbox.

Of course, the whole point of this fetch and pop business is to be able to "automate the process." Scripts could be written on both sides, JNOS and Linux, to routinely pop mailservers, sort, and deliver the mail. If you run a gateway, or are thinking about preparing for emergency operations, keeping the mail moving between Linux, the internet side; and JNOS, the radio side, could prove to be a valuable addition to your skill set as a network administrator!

Procmail, the Icing on the Cake

Now that you have your mail sitting in /var/spool/mail/root, for example, you would usually enter the command mail to run the mail client program to read it, forward it, or reply to it, etc. But, you may wish to go one step farther and have procmail sort it into sender or "from" mailboxes! This is where procmail really shows its "stuff."

As mentioned above, procmail picks up where sendmail leaves off. After sendmail has delivered all mail to the /var/spool/mail accounts, procmail will move the mail again to sender mailboxes, people or organizations who routinely send you mail. So, for example, if you were to receive mail from the ARRL on a regular basis, you might have a mailbox named ARRL. Procmail would then populate this box with just email from the ARRL. The command mail -f ARRL would open this file in the mailbox format. (NOTE: If the .procmailrc file were empty or non-existent, then all mail remains in the /var/spool/mail accounts as usual, and does not get moved to any other destinations.)

Here is a very "bare bones" .procmailrc file from a "sample" host machine. As you can see, you may define your own variables too, such as MAILDIR which then can be referenced as $MAILDIR within the file, similiar to the shell. Each "recipe" begins with a ":0" line, followed by the string to key on, and then the mailbox where it will be delivered. (man procmail and procmailex show exhaustive detail in the man pages...)

Note the location of these mailboxes in /root, it is /root/Mail. (I have also used /root/mail.) So, the first account on this listing below would be /root/Mail/wa8rsa, and you would view the mail there by changing to the /root/Mail directory and issuing the command mail -f wa8rsa. Once this "recipe" is in place, all future mail from wa8rsa on the JNOS machine will end up in this mailbox once popped using the fetchmail/procmail combination!


# 04-24-04
# .procmailrc
# --------------------------------------------------------------
# Sample file for illustration purposes only...
# You need to customize for your setup.
#
# $HOME is a variable known by procmail
# It is implied that all the mailboxes "live in" $MAILDIR
# ka1fsb-3.ampr.org is the JNOS machine, 44.56.26.11
# --------------------------------------------------------------

MAILDIR=$HOME/Mail
DEFAULT=$MAILDIR/mbox

#----- Start of "known" users...
#----- Keyed on the "From " in the mail header
#----- These could be more spcific: wa8rsa@ka1fsb-3.ampr.org
#----- As it is, these users on any domain will be sorted out...
#----- If match on the * line, then mail goes to its mbox below
:0
* ^From.*wa8rsa
wa8rsa

:0
* ^From.*kr4ms
kr4ms

:0
* ^From.*ve1ama
ve1ama

#----- Example of a "From " organization
:0
* ^From.*arrl.org
ARRL

#----- This "traps" for any email with "Barnstable Radio Club" anywhere
#----- in the subject line.
:0
* ^Subject:.*Barnstable Radio Club.*
clubnews

#----- End of "known" users...

#----- These are keyed on the "To:" in the mail header
:0:
* ^TOka1fsb
ka1fsb

:0:
* ^TOroot
root

:0:
* ^TOsysop
sysop

:0:
* ^FROM_DAEMON
postmaster
This control file should be located in the same directory as the .fetchmailrc file, which woulld typically be /root, but which could also be located in any user directory on the system such as /home/some_user. (Don't forget to adjust the ownership and access rights for that user.)

NOTE : And a final caution, the .procmailrc control file remains in force no matter what you are popping, even your ISP! However, procmail is versatile enough so that you may "trap" and re-direct specific emails to their "correct" local accounts, based on who sent it, to whom it was sent, or even the subject line! It really can "split hairs!"

Conclusions...

I know this has been a "whirlwind" tour of mail transfers between JNOS and Linux, and am hoping that you have gained enough information and experience to continue learning more about this fascinating and very engaging topic! We have barely scratched the surface here... We popped the JNOS mailserver into a Linux account and then sorted that mail according to criteria found in the mail header. We also moved mail from Linux to JNOS. Many more options are available...

If there is any advantage to this fetch/pop approach, it has to be the relative ease with which you may automate mail operations. You could, of course, accomplish the same results manually, but utilizing the "batch" nature of these facilities, large groups of user populations may be handled with a few comprehensive commands.

Mail is a world unto itself! A vast combinatorial "problem" space; in other words, there are nearly an infinite number ways to do any given task! Begin slowly and stay with it! And remember, you can continue to improve your mail skills for as long as you want! (Just ask Eric Allman!)


(Courtesy KBNorton Computer Services)