chris@CALSTATE.EDU ("Chris Taylor") (11/15/89)
From: NOGVAX::DAVE 14-NOV-1989 14:31:08.57
To: CHRIS
CC:
Subj: FYI - starnine
From: NOGVAX::WINS%"<starnine!bid@uunet.UU.NET>" 14-NOV-1989 11:22:48.45
To: DAVE
CC:
Subj: RE- RE- Quick-Mail Bridge
Return-Path: <starnine!bid@uunet.UU.NET>
Received: from uunet.uu.net by nog.calstate.edu with SMTP ;
Tue, 14 Nov 89 10:22:32 PDT
Received: from starnine.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA17694; Tue, 14 Nov 89 14:21:40 -0500
Message-Id: <8911141921.AA17694@uunet.uu.net>
Received: from mac_smtp by starnine with TCP; Tue, 14 Nov 89 10:43:23 PST
Date: 14 Nov 89 10:41:34
From: Tom Biddulph <starnine!bid@uunet.UU.NET>
Subject: RE- RE- Quick-Mail Bridge
To: CalState.EDU!dave%starnine@uunet.UU.NET
Reply to: RE: RE- Quick-Mail Bridge
> Thus, my impression is that the bridge is asking my domain name server for
> IN type A records for "starnine.com" to which it receives a failure on. The
> bridge should then ask for IN type MX records for "starnine.com" before
> sending the mail to the default SMTP host. If the bridge asked for IN type
> MX records from my domain name server, it would get an address and then the
> mail would go 'direct'.
Well, I think we are getting somewhere. What you are describing sounds like a
"MacTCP" problem (if it is a problem) as opposed to a "bridge" problem. We pass
the destination "hostname" directly to the MacTCP name resolver. If you have the
"domain nameserver" option checked, it is passed to this system for resolution.
I don't think that MacTCP knows anything about the difference between asking for
an "A" address and an "MX" address. It just wants the IP address for the
specified system.
Let me think about things a bit more to see if I can come up with any type of
work-around. Your suggestions will be welcome, but if the only resolution is in
changes to "MacTCP", you won't see these for a while since we rely on APPLE for
this software.
-bid-amanda@intercon.com (Amanda Walker) (12/01/89)
In article <Added.gZR8Bdm00UkT4nmE9i@andrew.cmu.edu>, chris@CALSTATE.EDU ("Chris Taylor") writes: > I don't think that MacTCP knows anything about the difference between asking for > an "A" address and an "MX" address. It just wants the IP address for the > specified system. The MacTCP resolver, in fact, only seems to understand A, NS, and maybe CNAME records (I don't remember off hand). We ended up writing our own resolver, since you can enumerate the resolver cache in a documented way, in order to find out where the name servers are. It's a hack, but until Apple does a better resolver, it's the only way for an application using MacTCP to get things like MX or HINFO records. -- Amanda Walker InterCon Systems Corporation amanda@intercon.com
urlichs@smurf.ira.uka.de (Matthias Urlichs) (12/02/89)
In comp.protocols.appletalk Tom Biddulph <starnine!bid@uunet.UU.NET> writes:
< [...] . We pass the destination "hostname" directly to the MacTCP name
< resolver. If you have the "domain nameserver" option checked, it is passed
< to this system for resolution. I don't think that MacTCP knows anything about
< the difference between asking for
< an "A" address and an "MX" address. It just wants the IP address for the
< specified system.
<
MacTCP doesn't know anything at all about getting addresses from name servers.
The domain name resolver code is linked to your application (dns.o), and only
understands "A" records. MX-type records should be handled different from
A-records anyway.
<Let me think about things a bit more to see if I can come up with any type of
<work-around. Your suggestions will be welcome, but if the only resolution is in
<changes to "MacTCP", you won't see these for a while since we rely on APPLE for
<this software.
There is no workaround, or rather, getting an A record from the DNS and
sending the mail to your default SMTP host if it fails already _is_ the
workaround.
Putting DNS support into your mailer would be the better solution.
Suggested reading are of course the appropriate RFCs...
--
Matthias Urlichsjln@accuvax.nwu.edu (John Norstad) (12/05/89)
The current release 1.0 of the MacTCP domain name resolver does not support generalized name queries. In particular, the StarNine (Gatormail-Q) bridge can't look up MX records (at least, not without implementing its own name resolver like the folks at Intercon did in TCP Connect II) At Northwestern I've solved this problem by sending ALL outgoing SMTP mail to the default host, which is a "smart" UNIX box that knows how to look up MX records. I did this by configuring MacTCP with NO domain name servers and with a single entry in the MacTCP Hosts file for the default host. This forces the StarNine software to send all mail to the default host. I heard at Interop that the next major release of MacTCP will support generalized name queries. Presumably the StarNine folks will modify their bridge to make use of this feature when it is available. John Norstad Northwestern University jln@acns.nwu.edu
veizades@apple.com (John Veizades) (12/05/89)
MacTCP supports the following domain name queries A and IN-ADDR queries. Additionally MacTCP also makes use of the NS and CNAME records. Future versions of MacTCP will provide additional support for HINFO and MX queries and maybe even a generalized method of sending arbitrary queries. For a complete description of how the domain name resolver in MacTCP works (technical details) interested parties should read the MacTCP programmers guide and the MacTCP administrators guide both of these are available through APDA (Apple Programmers Developer's Association). Questions, comments?? John Veizades... MacTCP Engineer, Apple Computer
emv@math.lsa.umich.edu (Edward Vielmetti) (12/05/89)
In article <5570@internal.Apple.COM> veizades@apple.com (John Veizades) writes:
MacTCP supports the following domain name queries A and IN-ADDR queries.
Additionally MacTCP also makes use of the NS and CNAME records. Future
versions of MacTCP will provide additional support for HINFO and MX
queries and maybe even a generalized method of sending arbitrary queries....
Questions, comments??
John Veizades...
MacTCP Engineer, Apple Computer
Yes. By not implementing RFC 1123 (Host Requirements RFC) you make
it impossible to produce a compliant SMTP sender using MacTCP. I quote
the relevant chapter-and-verse:
5.3.5 Domain Name Support
SMTP implementations MUST use the mechanism defined in Section
6.1 for mapping between domain names and IP addresses. This
means that every Internet SMTP MUST include support for the
Internet DNS.
In particular, a sender-SMTP MUST support the MX record scheme
[SMTP:3]. See also Section 7.4 of [DNS:2] for information on
domain name support for SMTP.
Under these circumstances the hack proposed, defining only one smart
mail server host & having the sender punt all of its mail to this
host, is not only necessary but would appear to be the only reasonable
way to do it.
Not too good.
--Edminshall@kinetics.com (Greg Minshall) (12/07/89)
In article <EMV.89Dec4172155@picasso.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: > ... >Yes. By not implementing RFC 1123 (Host Requirements RFC) you make >it impossible to produce a compliant SMTP sender using MacTCP. I would just like to mention that I doubt that ANY implementation of TCP/IP "implements RFC 1123". Someday, maybe. Today, no. It's more of a target we are all aiming at. By the way, *my* question about the next release of the MacTCP resolver would be "will it be implemented as a driver?" (to support multiple simultaneous applications and to reduce start-up time). Greg Minshall Novell, Inc. minshall@kinetics.com 1-415-947-0998