Re: Zmailer shortcomings (re pop/imap clients)

[urlichs@smurf.sub.org (Matthias Urlichs)]

While we're on this subject...

I just found a problem with MX handling. 
Assume that the MX for somebody points to me. Therefore, the MX lookup
returns an error. Unfortunately, that host has an A record, therefore
smtp_neighbour returns a pointer to that host. Not good.

I can't just trash the A lookup because many idiots out there don't know 
what MXes are.  :-(

The system in question has an A record because they're using UUCP over TCP
to pick up their mail. SMTP delivery must take precedence over UUCP delivery
because otherwise we would run into serious problems.

I hacked around the problem by defining a new database, and augmenting
smtp_neighbour thus:

        smtp_neighbour (domain, address, A) {
+		local xx
+               if xx=$(block_smtp "$domain") ; then
+                       return 1
+               fi
                if host_neighbour "$domain". ; then
                        return (((smtp "$domain" "$address" $A)))
                fi
                return 1
        }

This fixes the immediate problem, but it's a very ugly solution -- mainly
because I have to remember to add new UUCP/TCP systems to this database..
I'd rather have an MX+A subtype for the bind database which returns
an A record only if there's no MX at all present.

NB: The block_smtp database is defined somewhere else.
Actually, it hangs off the multiple-access multiple-subtype gdbm-style
database I'm playing with right now. (Still somewhat flaky. But "multiple
access" includes multiple concurrent writers, which is why I'm doing this.)

-- 
In 1913 the first diving school opened. Graduates got a deep-loma.
                                -- "On This Day in History"
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/