mishkin@apollo.HP.COM (Nathaniel Mishkin) (03/02/90)
I'm trying to figure out why I'm having difficulty talking to certain
SMTP servers. Here's a sample dialog (output from my SMTP client):
Running AA18102
<cstacy@BBN.COM>,<gildea@BBN.COM>... Connecting to BBN.COM (tcp)...
220 bbn.com Server SMTP (Complaints/bugs to: Postmaster@BBN.COM)
>>> HELO amway.apollo.com
250 bbn.com - you are a charlatan
>>> MAIL From:<wba@apollo.com>
451 Nameserver timeout during parsing
>>> QUIT
221 bbn.com says goodbye to amway.ch.apollo.hp.com at Thu Mar 1 14:24:51.
<cstacy@BBN.COM>,<gildea@BBN.COM>... Deferred: No such file or directory
I understand why the "you are a charlatan" message is coming out.
(Presumably the server is back mapping my IP address and noticing that
it doesn't map to "amway.apollo.com".) This is just a nuisance message,
as far as I can tell. The real problem is the:
>>> MAIL From:<wba@apollo.com>
451 Nameserver timeout during parsing
Does anyone out there know what the SMTP server is trying to do that
might induce it to print out that message? All I can imagine is that
the server is trying to resolve "apollo.com" (although it's not really
clear why it'd bother). As far as I know, no one else is having problems
resolving "apollo.com".
Thanks for any help.
-- Nat Mishkin
Hewlett Packard Company / Apollo Systems Division
mishkin@apollo.comedwin@praxis.cs.ruu.nl (Edwin Kremer) (03/02/90)
In article <48f06f20.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: | I'm trying to figure out why I'm having difficulty talking to certain | SMTP servers. Here's a sample dialog (output from my SMTP client): | >>> MAIL From:<wba@apollo.com> | 451 Nameserver timeout during parsing | Does anyone out there know what the SMTP server is trying to do that | might induce it to print out that message? I've seen a (almost) similar behaviour on our sendmail daemon some time ago: it happened if sendmail was able to find the IP address for the domain it was resolving (in this case "apollo.com") *but* was unable to find MX records for that domain. By then, I concluded that it must be silly to define an IP address in the nameserver, and not to add MX records. Well, I just DIGged "apollo.com" and... yep, no MX records. Hope this helps, --[ Edwin ]-- -- Edwin Kremer (SysAdm), Dept. of Computer Science, Utrecht University Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Telephone: +31-30-534104 | UUCP: ...!uunet!mcsun!hp4nl!ruuinf!edwin Telefax : +31-30-513791 | Email: edwin@cs.ruu.nl [131.211.80.5]
oberman@rogue.llnl.gov (Oberman, Kevin) (03/02/90)
In article <2556@ruuinf.cs.ruu.nl>, edwin@praxis.cs.ruu.nl (Edwin Kremer) writes... >I've seen a (almost) similar behaviour on our sendmail daemon some time >ago: it happened if sendmail was able to find the IP address for the >domain it was resolving (in this case "apollo.com") *but* was unable to >find MX records for that domain. By then, I concluded that it must be >silly to define an IP address in the nameserver, and not to add MX records. > >Well, I just DIGged "apollo.com" and... yep, no MX records. Hmm. This clearly indicates a bad mailer. RFC1123 makes it clear that an MX record should not be required for all nodes, only those providing gateway services of come sort. The specific flow of the lookup should be to query for an MX record first and if any are found, try to get IP addresses for them in the order of the value of their preferences. If 2 domains show identical preferences, the system to use should be chosen at random. If no MX record is found, then a direct A query is made and any respose is used as the address. Very few systems in the world have MX records. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
david@ms.uky.edu (David Herron -- a slipped disk) (03/03/90)
>Well, I just DIGged "apollo.com" and... yep, no MX records.
This shouldn't make any difference. The SMTP daemon he's talking about
is MMDF which makes the assumption that a lack of MX records but a
presence of A records implies A => MX.
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- Now arrived at a nameserver near you: david@davids.mmdf.com