I'm writing a very simplistic smtp client into an embedded device (an electronic gadget). I've got the device plugged into the same router as my Linux PC (Fedora Core 14). To develop and test the client, I enabled sendmail on my PC to act as a local smtp server. I did this by removing the IP restriction from sendmail.mc and enabling the firewall to accept incoming messages on port 25.

This setup appears to be working... for the most part. Obviously, for development purposes, if I send a bad TCP frame (miscalculated checksum or something), I want to find my error, fix the code, and start over. When I do this and reset the device, sendmail seems to have a hard time going back to the beginning. After restarting the connection, it often replies back immediately with the STACK flag set, which I believe means it's trying to salvage the previous communication. I tried stopping and restarting the sendmail service (/etc/init.d/sendmail stop|start), thinking that would flush its memory, but that had no affect. In fact, the strangest behavior I experienced was when I stopped the sendmail service and (without restarting sendmail) turned on my device. It was still getting legitimate TCP SMTP responses from my PC! If I recall correctly, it's typically a message with the reset flag set... but no always. There seems to be some variation to how it replies when sendmail is stopped.

So two glaring questions come to mind:
1. Is there a way to flush sendmail's memory? I couldn't find a timeout or any other configuration setting that would facilitate this. I want to be able to quickly change my client software and begin a brand new connection on the fly.

2. What could possibly cause my PC to send back legitimate TCP SMTP responses when the sendmail service is stopped? I've double-checked my ps listing and found no instances of sendmail running. Is it possible my router is cacheing the last message from my PC and simply repeating it back to my device?