E-Mail for the Office
by Kurt Keller
Four years ago only very few people had it, nowadays it has become a must-have: e-mail at the office. Hardly any company, however small it may be, can afford not to have an e-mail address. If your company only has a single address, such as
email@example.com or firstname.lastname@example.org,
then things are pretty easy; a POP3 account with a local provider and a POP3-compatible mail reader are sufficient. However, only a single mail address for the whole company is more a pro forma exercise than anything else. If you get e-mail for your company, there should be more flexibility: a personal address for every employee whose job includes interacting with people from outside the company and function addresses such as email@example.com, firstname.lastname@example.org. Such a setup is much more efficient than the "a single address for everything" approach, but it is also more complicated and there are several ways this can be accomplished. Your provider or a consultant should be able to advise you which setup is best for you - one would think, but...
POP3 (Post Office Protocol version 3)
As sad as it is, far too many providers don't know what they are doing when they sell e-mail connectivity for companies. A popular hookup for smaller organizations is a single POP3 account for the whole company. The company has its own domain name, such as @yourcompany.com and every employee can have his or her personal e-mail address. Function addresses are possible too. All the incoming mail for the whole domain is stuffed into one single POP3 account and one of the many software tools written especially for this purpose fetches the messages at regular intervals, checks the headers of each e-mail and then distributes the e-mail messages to the correct mailboxes in the company's inhouse e-mail system.
Sounds perfectly good, doesn't it? Sure, unless you know about things such as RFC821, SMTP header addresses vs. SMTP envelope addresses and the like. (Don't worry if you hear these things for the first time, many providers who, contrary to you, SHOULD know, don't know about them either.) The problem with POP3 accounts is that at the very time the message is added to the POP3 mailbox, some vital information is lost: the SMTP envelope.
An e-mail message can be compared to an old-fashioned normal letter. Say you write a letter to all your clients, announcing lower prices for your services. Instead of starting with "Dear Mr. XYZ," you are a little less personal and write "Dear Customers." The recipient will then only be visible on the envelope you use to send the letter. All the letters will arrive safely at their destination - you think. They will arrive safely at the companies you sent them to, but whether they will be delivered to the person mentioned on the envelope depends entirely on the internal mail delivery system the company in question uses. If letters are delivered unopened, fine. If they are opened but delivered with the envelope attached, fine too. But what if there is a company foolish enough to open all letters, put them all together on the same pile, throwing away any envelopes, and afterwards starts sorting the letters for delivery inhouse? Who should get the letter starting with "Dear Customers?"
What company would be stupid enough to deliver mail this way, you ask? Every company using a single POP3-account, I say! Because this is exactly what happens. The header section of an e-mail message is just like the header section of a normal letter, you can more or less put in there what you want. And for example mailing lists don't mention the final recipients in the header. For delivery there is another part responsible, the envelope. When your provider receives an e-mail message for someone at your company, they look at the envelope, put the message itself in your company's mailbox and discard the envelope. The software your company will be using to periodically pick up the incoming messages checks the header of each message for some information about who the message should be delivered to. And if it is not mentioned anywhere, it can not properly deliver it. Simple, sad and true.
Sure, your provider can, for example, tweak their sendmail configuration to add additional headers to the e-mail messages which mention the recipient in the envelope, but there is no standard for this and what works with one software is completely useless with some other tool. Besides, multiple entries which look like valid recipients can cause problems as well.
POP3 is great for e-mail boxes checked by only one individual; but they are no good for sharing.
SMTP (Simple Mail Transfer
Another very elegant variant is an SMTP connection with your provider. This keeps the envelope intact right through to your server. But no advantages without disadvantages: an SMTP connection must be up 24 hours a day, which can be costly; the SMTP port is a popular target for attacks, both for break-ins and as a relay for spam.
If you can justify the cost for connecting around the clock, or at least a connection where your provider will call your host if there are incoming packets, then this surely is a nice solution. With packet filters, firewalls, outer filters or even sendmail configuration in addition to an appropriate DNS setup, attacks to your SMTP host can be taken care of.
If you have lots of mail and many employees with individual e-mail addresses or you need to be up-to-the-minute with your e-mail, then a dedicated SMTP connection makes sense.
ETRN (Extended TURN)
Wouldn't it be nice to have the advantages of an SMTP connection without the need to be up and connected around the clock? You are not the first one to think so. This is why the SMTP command TURN was invented. With an appropriate DNS setup, mail is sent to your provider and kept there in the SMTP outgoing queue until you connect to the provider's SMTP host and issue the TURN command. The provider's host then sends all the mail queued for your site via SMTP, including all the headers and the envelopes. TURN does simply turn around the role of the two hosts talking SMTP: usually the host initiating the connection is sending mail and the host being contacted is receiving mail; after TURN the host which initiated the connection receives mail while the host being contacted sends mail for the requested domain.
Luckily there is hardly any SMTP implementation supporting the TURN command: it opens an enormous security hole, as no check whatsoever is being made to ensure whether the host issuing the TURN command is also authorized to receive mail for the requested domain. Anybody could connect to your provider's SMTP host and issue the TURN command with your domain name, downloading all your queued e-mail.
Some implementations of ESMTP (Extended SMTP) support the ETRN command, which stands for Extended TURN. It is a security enhanced version of the original TURN command, but does require your own SMTP host to have a fixed IP address. If your provider supports ETRN, provides you with a fixed IP address, the DNS entries are correct and your inhouse e-mail system also supports ETRN or at least SMTP, then you can have the benefits of a dedicated SMTP connection without the disadvantages.
Instead of telling the provider's SMTP host "send all queued mail for my domain to me" as with TURN, with ETRN you tell it "try now sending all queued mail for my domain to where it should go." This command can be issued from anywhere, but mail will only be sent to your SMTP host and of course can only be sent there if it is online at that time. If your SMTP host is not online, messages simply stay in the queue. DNS-wise, your own SMTP host must be the mail exchanger for your domain with the best (lowest) priority and the SMTP queueing host of your provider must be a mail exchanger for your domain with a higher priority.
If UUCP is not available and a dedicated SMTP connection does not make much sense, then you should check for ETRN.
UUCP (Unix to Unix Copy Protocol)
Do you remember UUCP? An old, old protocol used back in the stone age of the Internet. However, for many e-mail setups it still is the solution par excellence - also today, even though many unknowledgable frown upon it. An UUCP hookup surely is MUCH better at any time than a single POP3 company account.
UUCP originally was developed to copy files from computer to computer over slow and unreliable modem links. Transferring e-mail also involves copying or moving message files from one computer to another. Nowadays UUCP is mostly used for e-mail connections. It can be used over TCP/IP and does not mean that there must be a modem or serial link or that the link has to be slow or unreliable. Contrary to all the methods discussed thus far, UUCP is not limited to e-mail; you can also do news and even file transfers, provided that you have the necessary permissions and the system is set up for it.
As with an SMTP connection, all the vital information is available to your server and gateway software. Since UUCP is a store-and-forward solution, rather than interactive, it does not invite hackers and spammers, such as for example SMTP does. There is also no need to be connected full time, nor do you need to have a fixed IP address. It can even be implemented without you having any TCP/IP in any part of your network. UUCP is a truly flexible solution for e-mail connectivity.
Unless a dedicated SMTP connection makes sense for you, UUCP is a very good choice. Even if you do have a full-time connection to the Internet, UUCP can still be a simple but effective way to prevent spammers from using you as a relay and avoid certain attacks.
http://www.pinboard.com/ business or http://www.pinboard.com/kurt/private
© Algorithmica Japonica Copyright Notice: Copyright of material rests with the individual author. Articles may be reprinted by other user groups if the author and original publication are credited. Any other reproduction or use of material herein is prohibited without prior written permission from TPC. The mention of names of products without indication of Trademark or Registered Trademark status in no way implies that these products are not so protected by law.
The Newsletter of the Tokyo PC Users Group
Submissions : Editor
Tokyo PC Users Group, Post Office Box 103, Shibuya-Ku, Tokyo 150-8691, JAPAN