YORK-INST(8)

NAME
MMDF - York NIFTP interface guide (release 2.1)

SYNOPSIS
How to go about connecting the York NIFTP code into MMDF(II)

DESCRIPTION

This document attempts to step through the process of adding the York University NIFTP interface to the current (II) version of the Delaware, Multichannel Memo Distribution Facility. This version of the document describes how to connected up release 2.1 YORKBOX code to MMDF(II). There is an accompanying document that describes the changes needed for release 2.0, which is rather primitive.

As may be guessed, this comes in two parts, the transmission and reception of mail. You should have already the relevant code in the directory .../src/niftp which will handle the format conversion and the actual MMDF interface. This should be compiled and will produce two programs. niftp - the outbound channel ni_niftp - the inbound channel The niftp program should be installed with the other channel programs. The ni_niftp program can be put in various places, as long as hhQ can find it. We keep ours in the x25 directory /usr/lib/x25 but it can be put anywhere so long as the relevant pathname is changed to fit.

IMPORTANT
Take a copy of the following programs in case you have to put them back in a hurry :- hhP hhQ mhhcp hhmail Compile and install niftp and ni_niftp.

OUTBOUND MAIL
First of all, a channel has to be set up in the tailor file, it is presumed that you can do this, if not then there should be some relevant documentation somewhere. The important part about the tailor entry, is the confstr entry. This is what MMDF uses to exec the York transport system. This should be something like MTBL niftp file="niftp.names" MCHN niftp name="niftp", que=niftp, tbl=niftp,
show="via Janet with NIFTP", pgm=niftp, poll=0, mod=reg, ap=jnt, confstr="/usr/lib/x25/mhhcp mhhcp $(FILE) $(ADR) $(SENDER)"
The Make like variables will be substituted for by the outbound NIFTP channel so that the first one contains the filename of the file containing the message, and the second one the symbolic address of the host that the message is being aimed at. One thing to be sure of, the niftp outbound channel must be able to exec the mhhcp program, mhhcp is often installed with restrictive modes. So its important to check what effective and real user id's niftp runs with to ensure that things work. Another point to note is the access permissions on /usr/spool/hhcp, the mhhcp program attempts to create a file in this directory and will obviously fail if the permissions are wrong.

The first change is to the program mhhcp, this is the interface between niftp and the hhP programs. This has been almost completely rewritten to do things in a cleaner way and to take a different set of arguments. It is now called in the following way. mhhcp [-s] filename TSaddress sender The optional -s flag causes queueing of the file in the hhcp directory without starting up the hhP program. This may be a saving if your outgoing mail usage has sharp peaks or is very high. The next two arguments are as usual, the sender is the return address in case of failure. This is stored in the PA file as part of the structure.

The exit codes of mhhcp are also changed to reflect the following. This means that modifications to hhmail are necessary as before these changes an exit code of 0 meant failure.
JNT_OK      - everything ok
JNT_TEMP    - a temporary error, retry may work
JNT_PERM    - a fatal error, reject this message

Other changes are made to hhP so that when a mail transfer is rejected, either for staying in the queue too long or being rejected by the target host, the rejected item is sent back to the sender address as supplied by mhhcp rather than to the controlling UID. Change and compile mhhcp, hhP, hhmail and install.

INBOUND MAIL

The changes made here are to link directly the MMDF system with the hhQ program. Essentially, MMDF requires a bit more knowledge about the incoming message. In the York mail system, this is taken care of by the program mailer however as there is only minimal processing to be done, the role can be taken over by hhQ.c. This does make it incompatible with the York inbound traffic however, unless appropriate changes are made to mailer, so as far as incoming traffic is concerned, its either got to be handled by MMDF or by the york mail interface. They can't coexist.

The changes to hhQ are fairly small, they consist of forking an instance of ni_niftp to pass the message onto MMDF, and then wait for the exit status to see if the message is acceptable to MMDF. If not, hhQ will send back a STOPACK indicating that the message was fatally rejected by the receiver.

  CAVEAT
This is not the best solution. A better solution is to pass this information back at the ER stage. This would mean far more changes necessary to the hhQ program and would probably result in a complete rewrite. This would make fitting to later versions of hhQ difficult. It does mean that temporary failures communicated by MMDF are not handled gracefully.
End of CAVEAT

The ni_niftp will decide what channel its coming in from by using the information in the network field (first argument) and the mapping table found in niftp.nets. This table should have the format Network-name-passed-by-hhQ:channel-name e.g. serc:niftp janet:niftp pss:nipss ... Compile amd install hhQ. Generate the table niftp.nets and run dbmbuild. After recompiling hhQ and installing, all that remains is ....

DEBUGGING
After this, things should work. As a test, the hhmail program that comes with the York release should be able to send messages outbound, provided the necessary changes have been made to it, so try bouncing a few messages sent by hhmail off a friendly local host that you know can relay JNT mail (ucl-cs will do). e.g. hhmail mmdf%ourname@friendly-host hello world EOF This should test the hhQ and ni_niftp interface.

The outbound side is fairly easy, the main problems comes with the exec of mhhcp. Other than that, the hhP will leave around logging files to show whats going on. Also try turning up the logging on channels to FTR which should reveal the exec command.

FILES
various files in /usr/spool/hhcp and in the NIFTP queue directory, although at the moment they only reside there for a few seconds unless something goes wrong.

BUGS
see Caveat above.

Any problems then contact me (Julian Onions) at the one of the following address

jpo@uk.ac.nott.cs

jpo%nott.cs@ucl-cs

or

Computer Science Group
University of Nottingham
Nottingham
NG7 2RD
(ENGLAND)
(0602) 506101 x 3595