[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Telnet to mail host replies connection refused

On Thu, Oct 12, 2000 at 06:41:30AM -0400, Paul McHale (pmchale@doubleesolutions.com) wrote:
> > Strongly recommend you take a look at this rant on problem reporting:
> Let's see if I can better address it using the points from a summary you
> mentioned.
> Point 1: The first aim of a bug report is to let the programmer see the
> failure with his own eyes.
> This really applies to bug reporting.  I did show what was indicating
> the problem.  Namely, telneting to the SMTP port.  Please see previous
> mail for syntax used.

telnetting to current host, on which add'l diagnostics are available,
is significantly different from telnetting to some random remote host
(say, your ISP's mailserver), in which the OS and mailserver are
potential unknowns, and logs aren't available.

> Point 2: In case the first aim doesn't succeed, and the programmer
> can't see it failing himself, the second aim of a bug report is to
> describe what went wrong. Describe everything in detail. State what
> you saw, and also state what you expected to see. Write down the error
> messages, especially if they have numbers in them.
> Did this.

Somewhat.  Not all data though.

> Point 5: Be ready to provide extra information if the programmer needs
> it.  If he didn't need it, he wouldn't be asking for it. He isn't
> being deliberately awkward. Have version numbers at your fingertips,
> because they will probably be needed.
> Didn't include version number.  It is sendmail 8.9.3 for debian slink.

This would have been helpful data.

> Point 6: Write clearly. Say what you mean, and make sure it can't be
> misinterpreted.  Above all, be precise. Programmers like precision.
> I think I was ...

I think you weren't <g>

Mind you, it's a bit of a personal nit right now.  I've been dealing
with several people (and remembering far too much time spent with
others) who simply ***CANNONT*** be precise in speach, and, worst case,
get upset when attempts are made to either supply or prompt for more
data.  I can't tell you how annoying this is.  And the context is
entirely non-technical, FWIW.

> > Anything regarding sendmail or port 25 in your system logs?
> Syslog had the following line.
> Oct 12 01:10:22 debian tcplogd: smtp connection attempt from localhost
> []

Ok, so the problem isn't networking.  I'd check the generic daemon or
specific application logs next.  We've already ascertained what the
problem is at this point, I'm merely doing a PM on the issue
reporting/resolution process.

> No other mention.

Ascertained how, exactly?

I'll typically run the following in /var/log when trying to find
something regarding "foo":

    $ find . -type f | xargs zgrep -l foo

...which then lists all files matching pattern.  Explore these one at a
time, or do:

    $ zless $( find . -type f | xargs zgrep -l foo )

...to automate the search.

If I were to say "no other mention", I'd make some mention of what I
searched and how to make this determination.

> > It ***helps*** to tell us everything relevant about a situation,
> > including whether or not you have command-line access to the system in
> > question.   We can't see your system or guess your network configuration
> > by telepathy.
> As shown in the syntax, I am running telnet from the command line.  

From what host?  To what host?  For what purpose?  With what error
messages?  With what access to hosts.  With what intermediate network
configurations?  There's a reason networking is such a bitch to deal
with -- there are a large number of variables, many outside  your
imediate  control.

> As far as network configuration, I am not sure what information would
> be important here.  I am running the telnet from the command line of
> the server.  I can ping out and have functionality in ftp.  I see the
> same error when using localhost.  Can you be specific when you say
> network configuration?

Again, telnet to localhost is significantly different from telnetting to
some arbitrary remote location.  You bypass a whole nest of issues
including gateways, routers, ISPs, and remote host configuration.  Much
simpler.  This is one reason why testing network stuff on localhost is a
good debug environment -- you've eliminated a bunch of variables.

Karsten M. Self <kmself@ix.netcom.com>     http://www.netcom.com/~kmself
 Evangelist, Opensales, Inc.                    http://www.opensales.org
  What part of "Gestalt" don't you understand?      There is no K5 cabal
   http://gestalt-system.sourceforge.net/        http://www.kuro5hin.org
GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0

Attachment: pgpfDZ_Nk2m4c.pgp
Description: PGP signature

Reply to: