[EMAIL PROTECTED] wrote:
>
> On Thu, Dec 31, 1998 at 08:18:51AM -0600, Randy Cain wrote:
> > > Randy tells me the domain in question is statesource.com.
> > >
> > > statesource.com. 1h50m30s IN MX 30 mail3.webzone.net.
> > > statesource.com. 1h50m30s IN MX 10 mail.webzone.net.
> > > statesource.com. 1h50m30s IN MX 20 mail2.webzone.net.
> > >
> > > mail.webzone.net. 1h51m26s IN A 205.219.23.67
> > >
> > > telnet 205.219.23.67
> > > Trying 205.219.23.67...
> > > Connected to 205.219.23.67....
> > >
> > > telnet 205.219.23.67 smtp
> > > Trying 205.219.23.67...
> > > telnet: Unable to connect to remote host: No route to host
> >
> > Actually, the error message I get this morning is this:
> >
> > boss 69# telnet 205.219.23.67
> > Trying 205.219.23.67 ...
> > telnet: Unable to connect to remote host: Connection timed out
> > boss 70#
>
> Right, but you didn't telnet to the smtp port.
Sorry, missed that in the Cutout.
>
> > This is on a machine that is NOT behind the firewall.
> > >
> > > Which implies to me that they're using some service to filter
> > > smtp connections on the primary MX. Not a smart thing to do.
> > >
> > > Something is broken. Either their packet forwarding or firewall.
> >
> > Actually, mail.webzone.net is not behind a firewall. If you do a
> > traceroute to mail.webzone.net, it does respond to the traceroute.
> > Anytime you try to traceroute to a machine behind a firewall, the
> > traceroute stops at the firewall.
>
> Ok. I'm still puzzled by the fact that I telnet to the telnet port
> but there's no route to host when I telnet to the smtp port.
>
> > I still maintain that it is a problem in the DNS. Granted they may be
> > trying something, but it boils down to, IMHO, a faulty entry in the DNS
> > for statesource.com.
>
> You're right. They shouldn't list an unreachable smtp port as
> primary preference mx for the domain.
>
> I'm puzzled that qmail doesn't automatically try the next preference
> mx.
But as I understand qmail, if it sees a TCP connection, then it thinks
it has reached the server. Our firewall is a proxy server, which by
their very nature seizes the connection from the interface, makes sure
that the request doesn't violate the policy for the interface, and
either honors the request or discards it. Since the interface the email
machine deals with is the trusted interface, it will try to connect to
the machine requested, which is the mail.webzone.net machine. The email
machine sees a TCP connection from the firewall.
Now, when mail.webzone.net doesn't answer, the firewall, AFAIK, receives
a ICMP redirect to go to mail2.webzone.net. Since ICMP redirects are a
DIRECT violation of the security policy, it will not pass this
information back to the trusted side.
Does this sound plausible??
> --
> John White
> [EMAIL PROTECTED]
> PGP Public Key: http://www.triceratops.com/john/public-key.pgp
