in reply to Socket weirdness

If you're already using qmail-smtpd and friends, set up recordio to record all input and output to your mail server. Then you should be able to identify problem sessions, and see what went on.

Alternatively, use a packet sniffer like tcpdump to monitor all traffic with the hosts that are having problems, then review the logs after a problem happens.

A few random thoughts...One problem that seems to particularly plague Windows mail clients is not sending a proper CR/LF pair at the end of each SMTP line. Another possibility is that you're not flushing your socket's output buffer and don't have AutoFlush turned on for it. I had a problem with an SMTP wrapper for qmail-smtpd that turned out to be an improper PIPELINING implementation on my end. All of those are easy to test, and make sure that your system handles them properly.

If none of that helps, well, post some code. :)

Replies are listed 'Best First'.
Re: Re: Socket weirdness
by dgaramond2 (Monk) on May 07, 2004 at 19:18 UTC

    Thanks for the ideas. I haven't resorted to tcpdump, but I do log all lines received from the clients and all lines sent from the program.

    The IO::Socket docs says autoflush is turned on by default since 1.18. I've just checked and it's indeed on.

    I don't implement EHLO & PIPELINING (yet).

    The core of problem is, my program has correctly received all the DATA as well as the ".", and has processed the transaction and sent the 250 line, but these clients don't seem to get it. Haven't checked the return value of $sock->close() as the other poster noted, will do that. I'll also try doing a manual $sock->flush().

      And you're sending "250 ...\r\n", right? Not sending a proper SMTP line ending could confuse some clients and not others.

      Also, is it possible the clients are timing out, because you're taking a very long time to process the message?

      I find that using something like snoop/tcpdump or truss/strace is a great way of getting a reality check on what my program is really doing, as compared to what I think it's doing. :)

        Yup, always "\r\n" (actually I got a little paranoid and always make a habit to write "\015\012", because sometimes I tinker on Windows).

        Timing out: don't think so. The timestamps on my log clearly show consistently only 1-2 second between done receiving DATA and sending the 250 line.

        Anyway, I'm gonna try to have a session with my client and will do tcpdump and strace as well. Thanks. (Argh, it's so frustrating not being able to reproduce this myself...)