⟦0b26f9504⟧

TextFile

UK Patch Kit for Sendmail 5.65 + IDA 1.4.2
==========================================

These patches and other associated files have been produced to make
the IDA Sendmail configuration more usuable in the United Kingdom -
they can cope with traditional differences between mailing practice
in the UK and elsewhere:

- The acceptance of reversed (Grey-Book) addresses, eg:

        uk.ac.umist.co.ap

  Although all local delivery uses RFC format, this version will
  accept reversed addresses, and will send them out on JNT if
  required. Reversing only takes place as a ``last resort'' - if
  there are any ambiguities, the address will be assumed to be RFC,
  although it is possible to override this for specific cases.

- Provision to cope with long NRS names - these are synonyms of the
  "short" (normal) names, eg:

        apollo.computation.umist.ac.uk

  Not only will this version recognise synonyms, but will also try
  to rewrite long names to short ones - this gives a more "standard"
  feeling.

- Provision to cope with partial names - if the most external element
  of an address is not a known top domain, sendmail attempts to
  find a match in a lower domain, eg, inside ac.uk,

        ap.co.umist -> ap.co.umist.ac.uk

  Note that the method used is the opposite of that used by the
  UK-Sendmail .cf files, in that it tries lower domains first. Thus
  from ap.co.umist.ac.uk, the following attempts will be made until
  a known name is found:

        ap.co.umist.ap.co.umist.ac.uk
        ap.co.umist.co.umist.ac.uk
        ap.co.umist.umist.ac.uk
        ap.co.umist.ac.uk

- JNT mailers are provided, along with options to indicate that
  default mail to a particular domain (eg. .ac.uk) is to use JNT
  mailer. [ It should be noted that this the system the kit was
  tested on does not have direct JNT access, and this part of the
  kit was thus not fully tested ]. Two mailers are currently
  provided, one which reverses the addresses before sending, and
  one which sends them out RFC format.

It should be noted that almost all the above features are really
new options, except for a few instances where behaviour is extended
rather than replaced. Sendmail managers can select all or none of
the extensions as required by their particular system.

The following describes the environment the release is intended
for, how to install the kit, and how to configure for the various
extensions as required.

The patches have been installed and tested on an Apollo DN3/4000
ring running BSD4.3 under Apollo OS10.1 - but with an upgraded BIND
(4.6). The ring has access to the Manchester ethernet, but not
directly to JNT - it uses a relay, sun.cns.umist, which is
directly accessible via TCP/SMTP. The aim has been to try to
deliver mail over TCP where possible, but otherwise mail must be
sent through sun.cns.umist.

UK-Sendmail
===========

The aim of this kit is to allow the IDA Sendmail to be used in the
UK, and is thus to a certain extent challenging the Uk-Sendmail .cf
kit. What are the advantages of using this one. Basically, they are
the advantages of using the IDA Sendmail. This is much cleaner than
either Berkeley or Uk-Sendmail kits, because there is hardly any
need to hack the .cf files - routing and other such information is
provided either by a set of databases external to the .cf file
itself. Furthermore, the use of BIND means that domains that use a
relay to access JNT, such as ours, should need little long term
maintenance - even if the mail destinations change. As an example,
the UK-Sendmail produced .cf contain many lines indicating where
UMIST traffic is to be sent, the mail that can be sent directly
over SMTP:

R$+@$+.cns.umist.ac.uk          $@<$1@$2.cns.umist.ac.uk>sun.ether
R$+@$+.ccl.umist.ac.uk          $@<$1@$2.ccl.umist.ac.uk>cclsun.ether
R$+@$+.ap1.ee.umist.ac.uk       $@<$1@$2.ap1.ee.umist.ac.uk>berlin.ether
R$+@$+.ap2.ee.umist.ac.uk       $@<$1@$2.ap2.ee.umist.ac.uk>serf.ether
R$+@$+.sn1.ee.umist.ac.uk       $@<$1@$2.sn1.ee.umist.ac.uk>sol.ether
R$+@$+.ap.co.umist.ac.uk        $@<$1@$2.ap.co.umist.ac.uk>phi.ether
R$+@$+.sa.co.umist.ac.uk        $@<$1@$2.sa.co.umist.ac.uk>suna.ether

All other mail is redirected through a relay. If any changes take
place, these lists must be changed, and the files re-circulated
manually. Although there are many domains in the other Manchester
faculties that can be accessed directly, there is no attempt made
to include these in the list. This leads to the situation where
mail from part of the campus to another often goes over the
long-haul X25 network, rather than the local area ethernet!
However, BIND allows us to maintain this information ``centrally''
- the various mailers don't need to be told explicitly when the
local domains are changed.  In the longer term, with possible
direct access to the Internet, this looks even more essential.

The Required Environment
========================

A key feature of the environment is the suggested environment is
the presence of the BIND name server (named). Essentially, BIND
replaces the /etc/hosts file but includes the following extras:

1) Hosts are oranised into domains - basically the same as the mail
   domains.
2) Mail relays can be given.
3) The resolver provides software for partial address lookups.

Thus BIND provides combined information - for many nodes almost all
the routing/naming information is available from the BIND tables.

A single distributed BIND network covers the Internet. However, if
you don't have direct Internet access, you can run BIND on any
network - which is what we do. It should be noted that the UK
extras expect long to short NRS synonyms to be inserted in the BIND
tables. For example, in the ac.uk domain we supply the following:

manchester      CNAME   man
nottingham      CNAME   nott
man             MX      1000 sun.cns.umist
nott            MX      1000 sun.cns.umist
*.nott          MX      1000 sun.cns.umist
*.nottingham    MX      1000 sun.cns.umist
sun.cns.umist   A       130.88.115.60
sun.cns.umist   A       192.88.116.254

(CNAME denotes a synonym, A a TCP address, and MX a mail relay with
a preference number), and in the man.ac.uk domain:

computer-science        CNAME   cs
electrical-engineering  CNAME   ee
cs                      MX      0 m1.cs
m1.cs                   A       130.88.13.4

Based on this information, the address:

        aidon@computer-science.manchester

is translated to:

        aidon@cs.man.ac.uk

From the last MX record above, sendmail discovers that mail to
cs.man.ac.uk should be sent to m1.cs.man.ac.uk, and it can also
find the TCP address to use. Note, if required, several possible MX
addresses can be supplied - they will be sorted into ascending
order of the preference values, with equal order entries placed
randomly, and tried in that order.

If all else fails, it is possible to run the Sendmail without BIND.
However, if the above functionality is required, it must be
supplied using static path and domain (name) tables - implying more
maintenance work and larger files.

If anyone is interested in our local BIND tables, they are welcome
to contact the address below. Sites in Manchester have direct
acccess anyway. However, it should be noted that the following are
expected:

- For all top domains, sample wildcard MX records (except UK).

*.arpa          MX      1000 sun.cns.umist.ac.uk.
*.com           MX      1000 sun.cns.umist.ac.uk.
*.edu           MX      1000 sun.cns.umist.ac.uk.
*.gov           MX      1000 sun.cns.umist.ac.uk.
*.int           MX      1000 sun.cns.umist.ac.uk.

etc.

You can find out the list from CT/t in ida/cf/Sendmail.mc. It
doesn't really matter what host you use here, although a valid one
might help, because it is normal to configure the sendmail so that
non-local mail isn't delivered this way - the names are just used
for name resolution.

- Similarly for uk domains (exception being now ac.uk, assuming you
are within .ac.uk).

$ORIGIN uk.

*.mod                   MX      1000 sun.cns.umist.ac.uk.
*.co                    MX      1000 sun.cns.umist.ac.uk.

- Similarly for ac.uk, with the exception of your local domain(s) -
local being those that can be accessed directly, and thus for which
full information must be provided in the BIND tables:

$ORIGIN ac.uk.
abdn                    MX      1000 sun.cns.umist
*.abdn                  MX      1000 sun.cns.umist
aberdeen                CNAME   abdn
*.abberdeen             MX      1000 sun.cns.umist
aber                    MX      1000 sun.cns.umist
*.aber                  MX      1000 sun.cns.umist
aberystwyth             CNAME   aber
*.aberystwyth           MX      1000 sun.cns.umist
afrc                    MX      1000 sun.cns.umist
*.afrc                  MX      1000 sun.cns.umist

etc.

- For the local domains, we add synonyms, eg:

manchester      CNAME   man
manchester-computing-centre     CNAME mcc

and at each level as appropriate.

However, don't be tempted to provide wildcard entries like the
above for the local domains. If you are going to do this, you need
to comment out a flag in src/conf.h which effectively disables
searching. We originally thought that we could produce mixed
long/short names. For example, if one left out the resource record:

*.nottingham    MX      1000 sun.cns.umist

Then taking:

        computer-science.nottingham.ac.uk

our patched sendmail and BIND tables would produce:

        computer-science.nott.ac.uk

Unfortunately, Uk-Sendmail and JNT/NRS software cannot cope with
this. This shows one of the differences between this configuration
and the NRS - NRS has two names, whereas we have synonyms at each
level. This shows that care must be taken lest the sendmail gets
caught out. Better solutions might be:

Stop using long names.

    The problem here is that some relays still do short -> long
    name expansion!

Have the compete name set under BIND.

    If someone wrote a script to do NRS to BIND generation,
    this might be feasible. In the longer term, if get Internet
    access, we will all have to start using BIND anyway.

How to Apply these Patches
==========================

This directory contains a number of different files, some
patches, some extra library files, and some examples. Some of
these files are mentioned in the text below, and should perhaps
be left here. However, the following groups should be dealt
with. Note: all patches are with respect to the distributed
version (IDA 1.4.2).

IDA Patches
-----------

The following files should be compied to ida/cf:

        *.mc *.m4 alter_top_domain

Also, cd to ida/cf and apply patch file ida.cf.patches, eg:

        patch < ../../uk.extras/ida.cf.patches

[Assuming this directory is uk.extras].

The latter will patch Sendmail.mc.

The .m4 files are sample configurations - ap.co.m4 is the one we use,
and sample.jnt.m4 is an example of using the JNT mailer.

Source Patches
--------------

Patching the source is a little trickier, as we have had to
modify the source to get it to run on Apollo OS10.1, let alone
the UK modifications, and the thing we have really tested is
the combination of these two sets. This directory actually
contains two mutually exclusive source patches: uk.src.patches
and apollo+uk.src.patches. It is recommended that you use the
former, unless you are running an apollo operating system in
which case you may prefer the others. However, I thought it
important to dispatch the stuff we have actually tested for
information.

A second problem with these patches is that conf.h and domain.c
are heavily changed. If you have implemented any other changes
it is likely patch will get confused. Thus to give you an
indication of what they are supposed to be, the files
uk.conf.h, apollo+uk.conf.h and uk.domain.c are enclosed. The
prefix before the filename proper indicates what it is for -
apollo+uk.conf.h is the version of conf.h with both the Apollo
and the UK mods. If patch gives up, it is suggested you look at
these files to see what is expected. Alternatively, you may use
them explicitly.

How to Configure Sendmail
=========================

This section deals with differences between the UK and standard IDA
versions, and does not cover the general configuration associated
with the latter. Generally, however, ignoring user aliases, the
following files are of interest:

src/conf.h              -       options for sendmail binary.
ida/cf/*.m4             -       each mail domain/host has
                                one of these.
ida/cf/Sendmail.mc      -       Template for .cf files, contains
                                documentation on .m4 file options.
ida/cf/domaintable      -       extra synonyms to augment and
                                override BIND.
ida/cf/mailertable      -       indicate which mailer to be used to
                                reacha particular host.
ida/cf/pathtable        -       hard routes. This requires the
                                pathalias program, available
                                separately.

It should be noted that the only those nodes that access non-TCP
networks (eg. JNT), and need to indicate routes, need use
pathtable. This effectively means those with JNT/X25 or similar
access, and who want to be more efficient than just indicating a
single relay host. We don't use it on our environment.

For the UK fixes it is easier to look at the different options in
sections:

Ignoring Self MX's
------------------

There is a feature of the official IDA release where if the best
mail relay for a given domain is the current one, the getcanonname
call (which talks to BIND to resolve the name) fails. This is a
signal that another mail route must be used. However, it is not the
only way, and I suggest you leave IGNORE_SELF_MX commented out in
conf.h - which disables this feature. See conf.h for more details.

Ignoring BIND Failures during getcanonname
------------------------------------------

The current version of sendmail is not really designed to cope with
BIND failures during getcanonname - although when delivering over
SMTP, it will realise there are problem and will queue the mail.
Probably if there are problems during getcanonname too, the mail
should be queued. However, this is tricky and is not implemented.
It is difficult to see if there really is a problem, but in New
Zealand, where access to the Internet is less than reliable, they
have developed a technique where they ignore the error, and carry
on. The basis of this is that in normal circumstances this will
lead to a delivery over TCP, and the mail will then be queued.
Everyone else is a little unsure of this. The feature can be
enabled by defining IGNORE_TRYAGAIN in conf.h, but I suggest you
leave it commented out to start with. If this really does prove a
problem, perhaps we should write the proper fix!

Accepting Reversed Addresses
----------------------------

There are two definitions of what this means, refered to as Levels
1 and 2.

Level 1:

        After all other resolution, if the right hand bit of the
        address is not a known top domain, but the left hand bit
        is, reverse and try again.

        This is enabled by defining UKORDER in the .m4 file.

Level 2:

        Additionally to Level 1, if the right hand bit of the
        domain is not a known top domain, but the left hand bit
        is in Class K, we prepend a string and try again. Eg.

                define (UK_RETRY_PREFIX, uk.ac)
                define (UK_RETRY_CLASS, LIBDIR/ac.uk.domains)

        defines the string and the contents of class K respectively.
        Given this,

                joe.bloggs@man.ee

        will be translated to:

                joe.bloggs@uk.ac.man.ee

        and thus to:

                joe.bloggs@ee.man.ac.uk

        using level 1 on a second pass.

        Level 2 is designed for a change over period from when
        local delivery uses NRS order, and is not really designed
        for extended use. Note that dire consequences occur if
        the first element of UK_RETRY_PREFIX is not a known top
        domain.

There is a basic problem with both of these, what happens if the
local domain is a known top domain, eg:

        mx.ac.uk
        ph.ox.ac.uk

Given,

        uk.ac.ox.ph

the basic rules will assume these are in the Phillipeans! To
overcome this, we put the problem cases in the domain table (in the
library). The files domaintable.lev1 and domaintable.lev2 contain
the known problem cases. Thanks to Malcolm Harper
(Malcolm.Harper@prg.ox.ac.uk) who derived them from the NRS tables.
The list is actually quite cautious, it is based on the union of
the UK and US top domains. Basically you need to insert the contents of
the relevent file into your domaintable - probably, this will
suffice.

Resolving Partial Addresses
---------------------------

Resolving partial addresses requires several different steps -
basically to ensure that you don't enable it unless you really want
it. This has been added because the IDA maintainers in the States
feel it is dangerous! This is unlikely, the worst thing that can
happen is that the top domain list is not kept up to date, an
external name comes in, and is then resolved to a local name. We
have been living with this for ages under Uk-Sendmail, and I don't
think it too problematical. I would recommend you use it, as it
makes mailing more natural. To enable it you have to do the
following:

- Make sure the following definition are uncommented in conf.h:

        #define TOP_DOMAIN_CLASS 't'

- Make sure that the following definition is commented in conf.h:

        /* #define DONT_DNSRCH 1 */

(The patches are shipped this way).

This will build a binary that will try to resolve a partial domain,
unless the name is identified as being ``full''. The algorithm is
as follows:

        If the name does not contain a '.', it is not full.
        If the last character of the address is a dot, it
                must be full.
        If the element after the last dot is in class t,
                the name must be full.
        Otherwise, the name is treated as not full.

As a safety mechanism, if there is nothing in class t - meaning
that no Ct or Ft lines appeared in sendmail.cf - all names that
contain a dot are treated as full. Also, again if there is
something in class t, if a found top domain does not appear in
class t, a warning is generated - assuming LOG is defined.

Thus the key to partial looks ups is to use class ``t'' as the top
domain list rather than the more standard ``T''. To enable this,
a shell script has been produced, run:

        alter_top_domain -t

to enable partial name resolution, and:

        alter_top_domain -T

to disable it. You will need to be in the ida/cf directory when you
do this - the script directly modifies Sendmail.mc, so be careful
to remove and remake .cf files explicitly if you change the setting.
Note that the patches are shipped using class ``T''.

You could define both TOP_DOMAIN_CLASS and DONT_DNSRCH, which
implies that a name without a dot will be resolved, but anything
containing a dot will be regarded as full. This is essentially
the same as if class t is empty. Under these rules, an address
such as:

        John.Forrest@umist

would, from our nodes, resolve to:

        John.Forrest@umist.ac.uk

However,

        jf@ap.co.umist

would fail.

Long To Short NRS Name Mapping
------------------------------

This has been amply described above. The functionality is enabled
by leaving the following definition in conf.h uncommented:

        #define LOOK_FOR_LONGSYNONYMS 1

without this, the only synonyms that will be found are very local.

Don't Relay Unknowns
--------------------

If you define DONT_RELAY_UNKNOWNS in the .m4 file, relaying only
takes place if the node can resolve the address itself - actually
if the right most element of the final derived name is in the top
domain list. This is added as a final protection, but it is
suggested that you don't use it unless you really want to be sure.
It may also be useful if you relay over JNT, because the expected
bad mail will come earlier in the cycle. However, if you do enable
this, you will have to keep the top domain list fully up to date.

JNT Mailer
----------

Two extra mailers are provided by the insertion of:

include(JNT.mc)

in a .m4 configuration file - see sample.jnt.m4 for an example.
This adds mailers JNT and JNT-A, which deliver JNT mail using
Grey-Book and RFC addresses respectively. They are only
partially tried, so be careful, but are based on the
Uk-Sendmail equivalents and can't be far out. To use the
mailers you have to indicate the nodes/domains for which they
should be used - with IDA this means in the MAILERTABLE - the
default being always TCPMAILER. To say that all ac.uk routes
are to use JNT, you need to add the following to the
MAILERTABLE:

        JNT:%s.ac.uk    .ac.uk

The %s is replaced by the remainder of the address (the bit
before .ac.uk) - this is an extension of these patches,
although it may become standard. The above is not terribly
useful, as all mail to .ac.uk will go over JNT, and everything
else by TCP, which is hardly likely. To indicate the routing, a
"map" is required - via pathalias. However, a quick fix is to
relay through one of the major relays, eg:

        define(RELAY_MAILER, JNT)
        define(RELAY_HOST, nsfnet-relay.ac.uk)

To indicate that all local mail could be reached over TCP, add
entries to say so in MAILER_TABLE, eg:

        TCPMAILER:%s.umist.ac.uk        .umist.ac.uk
        TCPMAILER:%s.man.ac.uk          .man.ac.uk
        TCPMAILER:%s.mcc.ac.uk          .mcc.ac.uk

In practice it is likely that there are some local nodes that
should also be accessed over JNT, and these should be given
explicitly. Eg:

        JNT:pa.cn.umist.ac.uk           pa.cn.umist.ac.uk

AUTHOR
======

John Forrest
Dept of Computation
UMIST

Tel: 061-200 3315
Mail: John.Forrest@umist.ac.uk

Many thanks to Neil Rickert for the UKORDER stuff.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦0b26f9504⟧ TextFile

Derivation

TextFile
