It seems like using -o on tcpserver fixed this problem. -o stops tcpserver
from calling setsockopt().
Discovered by running qmail-smtpd from inetd from where it worked just
fine.
Regards.
On Mon, Apr 03, 2000 at 09:04:53AM -0500, Bruno Wolff III wrote:
> This sounds a little like a problem that was reported to the bugtraq
> list last week.
> There are some places that are sending back broken packets. From memory,
> it was in response to pactkets setting socket options and these options
> were sent back as data. This primarily affects linux systems.
>
> On Sat, Apr 01, 2000 at 07:39:13AM +1000,
> Jon Jenkins <[EMAIL PROTECTED]> wrote:
> > Greetings,
> >
> > I'm having a problem whereby SMTP connections from certain mail-servers work
> > fine and from other servers there is a big problem (all packets appear to
> > disappear or get disregarded). Most of the ISP's servers fail (including the
> > secondary MX).
> >
> > The ISP has:
> > 1) Traced the packets as far as the ISDN router.
> > 2) Double checked the router config.
> > and say that everything is fine ...
> >
> > The router (CISCO 801) maps ports 25 and 53(TCP & UDP) through to the SCO
> > box.
> >
> > qmail-smtpd is running under tcpserver with -v for logging purposes ...
> >
> > The config for qmail is very simple.
> >
> > Some servers at the ISP can (and do) telnet to port 25 and get a "good"
> > connect and manage to get through the smtp session and mail entered is
> > delivered.
> >
> > Others receive the "banner" but everything else sent gets "lost" and
> > eventually
> > the session times-out.
> >
> > There are no "deny's" on the router or on SCO,(that I can find)
> >
> > What can any-one suggest ... depression is setting in.
> >
> > Jon Jenkins
> >
> >
> >
