🚀 go-pugleaf

The postmaster at amtp.cam.ac.uk has pointed out a problem with the address
expansion done by our sendmail configuration.  We are mapping the address
                user@atm.amtp.cam.ac.uk
to              user%atm.amtp.cam.ac.uk%uk.ac.cam.amtp@uk.ac.cam.amtp.lat
despite the fact that atm.amtp.cam.ac.uk has a direct NRS registered address.

He mentioned that other sites seem to have this problem too.

We are using the janet.chn tables (ie application relays information) from
C-nrs, but do not use a table of non-relayed JANet hosts.

The problem seems to stem from ruleset 16:

#  initial match failed, retry with successively higher level domains
R<$+@$+>                $:<$1%$2@$2>            u@a.b.c -> u%a.b.c@a.b.c
R<$+@$-.$+>             $>17$1@$3               retry routing

which turns     user@atm.amtp.cam.ac.uk
into            user%atm.amtp.cam.ac.uk@amtp.cam.ac.uk
and then ruleset 17 finds the NRS registered application relay for 
amtp.cam.ac.uk and rewrites the address as
                user%atm.amtp.cam.ac.uk%uk.ac.cam.amtp@uk.ac.cam.amtp.lat

I have also noticed (when using sendmail -bt) that this loop in ruleset 16
seems rather wasteful, as in
        user@rice.edu   -> user%rice.edu@nsf.ac.uk
                        -> user%rice.edu%nsf.ac.uk@ac.uk
                        -> user%rice.edu%nsf.ac.uk@uk
                        -> user%rice.edu@nsf.ac.uk
where each call to ruleset 17 involves two calls to ruleset 9 for NRS/RFC822
domain conversion, plus a lot of other work.

So, has anyone using UK-2.1 solved the problem of recognising NRS registered
JANet sites to avoid the "retry with successively higher level domains" loop?
If so, is the larger channel table (using IDA databases) any less efficient
than the retry loop?  Can this be done with the abbrev.dom table from c-nrs,
or is a new table needed?

-- Malcolm Harper