Weird logs during direct connection

[catap]

As part of testing of 2.62 I've tried to use spampd as SMTP server, and discovered this in logs:

Dec  9 14:59:27 matebook spampd[67475]: Use of uninitialized value $msg[0] in chomp at /usr/local/sbin/spampd line 217, <GEN5> line 7.
Dec  9 14:59:27 matebook spampd[67475]: Use of uninitialized value $msg[0] in join or string at /usr/local/sbin/spampd line 218, <GEN5> line 7.
Dec  9 14:59:27 matebook spampd[67475]: Use of uninitialized value $destresp in concatenation (.) or string at /usr/local/sbin/spampd line 1154, <GEN5> line 7.

here a telnet session which I made:

$ telnet 127.0.0.1 10025
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 matebook.local ESMTP OpenSMTPD
HELO fake.domain.tld
250 matebook.local Hello fake.domain.tld [127.0.0.1], pleased to meet you
MAIL FROM:<sender@example.net>
250 2.0.0 Ok
RCPT TO:<recipient@example.net>
250 2.1.5 Destination address valid: Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Subject: Test spam mail (GTUBE)
Message-ID: <GTUBE1.1010101@example.net>
Date: Wed, 23 Jul 2003 23:30:00 +0200
From: Sender <sender@example.net>
To: Recipient <recipient@example.net>
Precedence: junk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is the GTUBE, the
        Generic
        Test for
        Unsolicited
        Bulk
        Email

If your spam filter supports it, the GTUBE provides a test by which you
can verify that the filter is installed correctly and is detecting incoming
spam. You can send yourself a test mail containing the following string of
characters (in upper case and with no white spaces and line breaks):

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

You should send this test mail from an account outside of your network.
.
250 2.0.0 54e90c11 Message accepted for delivery
QUIT
221 2.0.0 Bye
^CTerminated 
$

also, it hadn't closed the session after QUIT and I was forced to kill my telnet

[mpaperno]

Hi, thanks for the report.

Could you enable spampd debug logging and run that again? I'm not clear on which response it fails to parse (the Bye?) or what could possibly be sent after that.

Though I do see that client->hear may return a null string... which AFAIK hasn't happened enough since ~2003 for anyone else to report :)

It does expect the server side to terminate the connection, so you'd need to shut down the terminal session manually, which is expected.

Thanks,
-Max

[catap]

Here a debug log with -d all: spampd.txt

[mpaperno]

Thanks! I don't see any errors in here, so I'm still not sure where/when exactly the other logged errors are coming from. I realized those could be from anywhere in the communication process, not just at the end.

Only thing I noticed is it took 6 seconds after "Bye" to disconnect, but I'm assuming that's how long it took you to quit the terminal session...

Mon Dec  9 15:36:51 2024 [53677] dbg: Destination response: '221 2.0.0 Bye'
Mon Dec  9 15:36:57 2024 [53677] dbg: Closed connections

[catap]

@mpaperno I think I needed something like 6 seconds to switch to another terminal and kill telnet.

[catap]

I had a dig a bit and seems that it is "blocked" inside $smtp_server->chat, after FIN from smtpd.