nessus@mit-eddie.MIT.EDU (Doug Alan) (11/27/86)
Now that we have uucp addresses that look just like internet
addresses, there is a problem in making one's "sendmail.cf" figure out
when to dispatch a piece of mail to the tcp mailer and when to
dispatch it to the uucp mailer. Sendmail, as far as I know, can't be
configured to check with "named" to see if a mail address is an
internet address or not. It only allows you to have "named"
canonicalize an internet address. jbs here figured out that to check
if an address is an internet address, you can add a "." to the end of
the address and then have sendmail canonicalize it. If it wasn't an
internet address, the "." will stay there. This is a kludge, though,
and it can also be kind of slow.
What's the right solution? Also, where do I get a version of sendmail
for 4.3BSD that supports MX? And who is responsible for making this
horrible decision that different zones should share the same top level
domains?
|>oug /\lan
P.S. Why won't won't sendmail let me put a rule like
R$*<$* $2
in the config file? It keeps complaining about an unmatched "<". If
it's going to complain about unmatched "<"'s in rewrite rules, then it
should parse nested angle-brackets propperly, and shouldn't allow
addresses with unmatched "<"'s into the system. Because of this set
of misfeatures the parser will loop if some bozo hands it an address
like "<<<<<<<<<<foo@bar@baz@bax>>>>>>>>>>"
--
Nessus@Eddie.MIT.EDU
{allegra,seismo,decvax!genrad}!mit-eddie!nessus
MIT, E40-358a, Cambridge, MA 02139 (617) 253-0147david@ukma.ms.uky.csnet (David Herron, NPR Lover) (12/04/86)
In article <4058@mit-eddie.MIT.EDU> nessus@eddie.MIT.EDU (Doug Alan) writes: >Now that we have uucp addresses that look just like internet >addresses, there is a problem in making one's "sendmail.cf" figure out >when to dispatch a piece of mail to the tcp mailer and when to >dispatch it to the uucp mailer. ... > >... And who is responsible for making this >horrible decision that different zones should share the same top level >domains? hehehehe "Fixed in MMDF" MMDF *never* had this sort of problem ... -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet (I'm also "postmaster", "news", "netnews", "uucp", "mmdf", and ...) "What have I got in my pocketses?" -- I never heard such a stupid damn riddle!
david@ukma.ms.uky.csnet (David Herron, NPR Lover) (12/06/86)
> From: Jeff Siegal <jbs@eddie.mit.edu> > > In article <5259@ukme.ukma.ms.uky.csnet> you write: > >In article <4058@mit-eddie.MIT.EDU> nessus@eddie.MIT.EDU (Doug Alan) writes: > > > > > >hehehehe > > > > > >"Fixed in MMDF" > > > >MMDF *never* had this sort of problem ... > > Responses of this type don't seem (to me) to help anyone. > > Could you kindly post info on _how_ MMDF gets around this > problem, so that others can benefit from possible design > advantages of MMDF. > > Jeff Siegal OK... since ya asked (BTW folks, this is private mail that I'm quoting, hope Jeff doesn't mind)... MMDF seperates keeps the domain table(s) seperate from the routing table(s). One first designs a set of tables which describes all the domains. Then one designs another set of tables which describes the networks to which you are attached, and the domains which are present in each network. When the message comes in the domains are first "regularized" by looking in the domain tables to find the specific domain name. (Partial domain names are handled at this point by making repeated lookups stripping off lower levels of domains until an entry is found). Attached to each entry in the domain table is the "official name" for that domain. This "official" name is the tag used when looking in the channel tables. For each channel you list the domains to which you can send mail... the first channel which has the "official name" listed in it is the one through which the message is sent. There is also some validation going on here, one must be authorized for sending into particular channels. I suppose (but don't know because I've never done anything with authorization (yet)) that if the domain name were reachable by another channel, and a particular sender were not authorized for the first channel, that the message would travel through the second channel. "Out of the box" the scheme supports internet and uucp routing. I'm slowly building software to work nicely with bitnet as that is the third network we are attached to. Each of the three networks are at some stage of domainization at this point. A host can potentially appear in the channel table for all three networks. (In fact, this host I'm on now *really*does* appear in all three networks, just not with the same name (yet)). Sendmail on the other hand apparently has severe problems in doing something of this sort. My memory of the specifics is poor since it's been a couple of years since I tried to configure sendmail, and I never was able to get a good configuration. However, as I recall, the only kind of tables there can be are domain tables. There wasn't a way to have a domain-name to delivery-channel mapping... (would somebody who knows better please followup) I apologize for the tone of my earlier answer... I hope this answer is more useful. -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet (I'm also "postmaster", "news", "netnews", "uucp", "mmdf", and ...) "What have I got in my pocketses?" -- I never heard such a stupid damn riddle!
gds@sri-spam.istc.sri.com (The lost Bostonian) (12/13/86)
If eddie.mit.edu is sufficiently "smart" (able to resolve a good % of uucp addresses) it might consider becoming authoritative for that % of uucp addresses in the domain namespace, rather than handing off those requests to some other site that accepts queries for MX records. I admit that this can be a political as well as technical issue. eddie.mit.edu might not want to accept queries and forward mail from the whole Internet to a certain % of uucp hosts, even if much of that traffic is already being directed into the uucp network via eddie.mit.edu. --gregbo