Today we continue with network services. In this lab we work with mail servers and web proxies. There are two, mostly unrelated parts to this lab. In the first, you will learn a little about SMTP and email management. In the second, you will learn about proxy caches (Squid, in particular), and using them as filters.
First, make sure that postfix, the default MTA on our CentOS machines, is running, and that the telnet client is installed. Then send the root account some test mail (when you are logged into a sandbox machine) by telneting to localhost, using the SMTP port, and sending the following, line-by-line:
HELO mail-from.anywhere.edu MAIL From:<someone@cse265class> RCPT To:<root> DATA To: The root account via nobody <nobody@home> From: Your friendly neighborhood SMTP programmer <could-be-anyone> Subject: a really short email Hello, this is a test. I could say anything I want. And it could be a long message, except that when I put a period (.) on a line by itself, the message is over. . QUIT
If you are logged in as root with root's environment, you can read root's mail, with a mailer such as /bin/mail (or any other mailer that can access your mail locally). If you haven't read mail as root on your machine before, you probably have other mail waiting (log reports, cron failures, etc.). As you can see, it is trivial to disguise who you are sending to, and who the message is really from. If you were to use a mailer that can show you the headers, all that you would see is that the mail server received this message from itself. At this point, I should point out that Lehigh has multiple policies relating to security and information access and that sending mail without correct identification is likely to be a violation of one or more policies. In this assignment, you are required to send mail to accounts that exist on your machine only.
Before going further, let's change your postfix configuration to prevent such obviously bogus mail from being accepted. Find the postfix configuration files and see what they contain. You'll need to add a parameter to reject obviously invalid email destinations. (This may require some digging.) Make the change and test it by attempting to send the above message again. If your change was successful, you should get back an error message of some kind from the MTA when you re-try to send it. Verify that you can still send mail to root if you use valid information.
Recall that back in lab #5 there were pointers to Perl tutorials and documentation. There are many standard modules in Perl, including IO::Socket, which is one that you'll need for this project. Here is a minimal example of using IO::Socket to create a TCP connection to a server, and sending and receiving lines of text.
use IO::Socket; $socket = IO::Socket::INET->new("$remote_host:$remote_port"); # "localhost:80", for example. print $socket "data\n"; $line = <$socket>;
If the above code snippet is unclear, I suggest working through some of the Perl tutorials and documentation. The perl.org documentation for IO::Socket::INET can be found here.
Your task is to write a short Perl script that will ask the user for the to-address and from-address and the contents of a mail message, and send that message by connecting to your mail server on the SMTP port of your localhost. It must tell the user of success in sending the message, or show the MTA error message (such as for the bogus message described at the beginning). You may use any of the standard libraries, such as IO::Socket mentioned above, but you may not use any mail-oriented Perl libraries, even if they are installed on your machine.
You might want to go on to Part II first if you are not comfortable programming in Perl.
The Squid web proxy cache may have been installed as part of your OS. If needed, install squid using yum. Go ahead and start it, in the usual way. When it is running, ps and top will show a couple of squid processes. To use the proxy, you need to point your browser to it. In Firefox, find Connection Settings. Select manual configuration, and fill in the HTTP blanks with localhost as the name of proxy, and 3128 as the port number.
Once you press OK, future requests issued by the browser will go through the squid proxy cache instead. There are many configuration options for Squid, and the configuration is found in /etc/squid/squid.conf. Every request that goes through Squid is logged, not surprisingly in files in the directory /var/log/squid. In particular, the access.log file contains every request, whether it was served from cache (a HIT), the size, the response code, etc.
One advertised advantage of a proxy cache is to be able to filter objectionable content. That is, if you had a list of URLs that were objectionable, the proxy can usually be configured to block requests for those URLs. Squirm is an example package that provides significant filtering and redirecting to Squid. In this part of the project, and with the (misguided) goal of school spirit, your job is to block access to any Web page within the lafayette.edu domain. You should do so through appropriate modifications of the squid configuration file, but not through the use of a redirector like Squirm. Note that I do not expect you to block cached content (e.g., from Google) from that domain, but just to prevent direct access through your proxy for any URL within that domain, such as www.lafayette.edu. Note, however, that it should function normally for other domains (i.e., you should still be able to access lehigh.edu sites).
Hint: If you have previously visited Lafayette from this browser, you may need to clear the cache before your filtering becomes effective.
If you have time, you might want to work on the latest homework that has been posted.