TPC.INT: Fax Server Internet Connection

Does my fax server need to be connected to the Internet 24 hr/day before I can become a "cell" and relay faxes from TPC.INT?

The long answer includes the following connection types and the issues related to each.

This type of connection to the internet is preferred. Systems that are attached to the internet in this manner can receive and send e-mail on demand, and will always be available to receive messages sent via tpc.int. This includes Frame relay lines, co-hosted servers, and servers connected to a LAN which has tcp/ip routing to the general Internet. This will work well with UNIX and Windows servers. Logging features of the TPC glue code can also be used with direct connections.

UUCP is an older protocol, however it is still the preferred method of dealing with e-mail servers that are not connected to the internet 24/7.

Currently, UUCP is prevalent on Unix system such as SunOS and Linux. You can set up a server with a UUCP feed from a host on the internet and call in once every few hours to exchange e-mail, and disconnect. Faxes can be delivered in-between UUCP calls. For light duty cells, you can run both the UUCP dialout and Fax calls on one modem/phone line. The Portland Oregon cell operates this way.

UUCP can also run over TCP/IP. It is entirely possible to call your local ISP with PPP and then fetch your mail via UUCP over TCP from another mail relay host from another area altogether. You do not have to make a special call to an ISP just for the UUCP data.

If your ISP is already providing UUCP you have a registereddomain name with the Internic, you can add a second UUCP feed to your mail server. The second connection can be used to contact the TPC UUCP server and collect the e-mail/fax messages for processing on your server. UUCP supports multple mail sources, so you would use one for regular mail, and the other for TPC mail. You can also have your ISP feed your TPC messages to you with your existing UUCP feed however your ISP will need your sendmai.cT file listing all theTPC mail domains you support.

If you do not have a UUCP feed, Mr Hewes can provide you a limited feed for your area's fax coverage. This feed will not forward all e-mail for any given domain name, it will only service tpc.int subdomains. If you already have a mail feed (UUCP or otherwise) for your e-mail and do not want to involve your ISP in configuring their system to relay tpc.int addresses, you can add a second UUCP feed for tpc.int in addition to your existing e-mail feed.

Windows support: It has been reported that UUCP is available for windows servers, however we do not have any experience with this type of system.

Some ISPs offer e-mail on a standard SMTP style protocol via a static IP address, however the target system does not stay connected 24/7. Here is how it works:

Your ISP operates a DNS server with an entry for your system This record is an "MX" record (Mail Exchange) however this MX record directs e-mail to your ISP's mail server.

Your ISP's mail server stores the e-mail in it's SMTP queue, and attempts to deliver it to the static IP address given to your your system. If you are not connected, your ISP's mail queue will try again later. If you are connected, it will deliver it to you on your system's SMTP mail port.

Two disadvantages: You must stay connected for a minimum period of time which exceeds the queue run period of your ISP. If your ISP runs their mail queue every 5 minutes, you must stay connected for a minimum of 5 minutes. Some mail servers can use the ETRN command to force immediate de-spooling, but not all support it. The second disadvantage is that this method requires a static IP address. Most dialup PPP service providers use dynamic addressing, so you must request this when provisioning PPP services.

This type of connection works well with ISPs or Fax server systems that can operate SMTP e-mail but do not have UUCP capability.

Your ISP providing this type of mail transport will also have to configure their e-mail relay system to accept and forward TPC.INT based addresses as well as your standard e-mail. The easiest way to do this is to provide them with a copy of the sendmail.cT you generate when configuring the tpc glue software for Unix.

The reason: When SMTP e-mail is exchanged, the mail server refers to the e-mail in 2 parts. The Envelope and the Content. The envelope of a message contains the target e-mail address of the person who is to receive the mail. The Content contains a "To: <user>" line that may or may not match the envelope.

When storing a message and using POP to retrieve it, the SMTP envelope is lost, and the client must trust the Content "To:" header line to be accurate.

Because TPC uses the target e-mail address to specify the fax number (i.e. remote-printer@7.3.0.3.1.9.6.3.0.5.1.tpc.int), it is imperative that the target fax server receive the entire SMTP envelope. If not, the "To:" line must be used, and it may not be accurate.

Several of the RFCs listed below do not use the term "Envelope" and "Content" to describe the different parts of an e-mail exchange so the following example is provided to show the difference.

--> [open TCP connection]
<-- 220 hostname: Sendmail 8.6.9/8.6.9 ready
--> HELO client.lan.net
<-- 250 hostname: hello client.lan.net
--> MAIL FROM: <anyuser@client.lan.net>
<-- 250 Sender OK.
--> RCPT TO: <remote-printer@7.3.0.3.1.9.6.3.0.5.1.tpc.int>
<-- 250 Recipient OK
--> DATA
<-- 354 Enter e-mail, end with "." on line.

[ Envelope ]

--> Received: (from anyuser@localhost) by client.lan.net
--> (8.8.5/8.8.5) id VAA15646 Sun, 1 Mar 1998 21:20:37 -0800
--> Date: Sun, 1 Mar 1998 21:20:37 -0800
--> From: Any User <anyuser@client.lan.net>
--> Message-Id: <199803020520.VAA15646@odell.sdesign.com>
--> To: remote-printer@7.3.0.3.1.9.6.3.0.5.1.tpc.int
-->
--> Hello this is a test
--> more testing

--> .
<-- 250 Message excepted
--> QUIT
<-- 221 Closing connection.

[ Content ]

Notice that the Envelope "RCPT TO:" and the Content "To:" lines have the same e-mail address in this example. In the real world, these addresses do not always match, and will cause problems with the TPC delivery mechanism.

In this example, the mail is generated by a mailing list. The Content "To:" reflects the target address as the mailing list, however the Envelope directs the mail to its' destination. If a fax server is using POP to request e-mail, the envelope is stripped when the e-mail is placed in the POP mail box, and the fax server will not be able to deliver the fax based on the Content "To:" line.

The basic design of TPC and the TPC glue is that of a MTA (Mail Transfer Agent) which is the same as other MTAs such as Sendmail, SMail, QMail, UUCP, and the like. These systems are designed to exchange and forward e-mail messages to other systems.

POP and IMAP are MUAs and are not designed to be used to forward or exchange email other than with the end mail reader. Because TPC is a e-mail-to-fax-machine forwarder (MTA) it will not work well as when interacting with an MUA.

For further information on Internet based e-mail, you should review the following:

Fax Server Internet Connections