Topic: Qmail From Outside Stopped Working

[Dan G.]

Hi,

Three days ago, unrelated to anything I can recall, my primary SME V5 server stopped receiving mail on the external interface.  If I telnet to port 25 from the internal network, I can establish a session just fine.  All attempts to get to the SMTP service from outside fail.  From this primary email server, I can telnet to port 25 on another (experimental) SME box in the same external subnet --- but I can't do the reverse.   The other SME box cannot connect to port 25 of the primary server.  I applied SMEServer v5.0 Update 3 today, and nothing changed for the better.

I had previously installed, then removed ipportfw rpm for e-smith, and I'm not sure if it is related to that.  

Strange message in maillog:

@400000003c04e54013b21b4c alert: oh no! lost spawn connection! dying...
@400000003c04e54013b24644 alert: oh no! lost spawn connection! dying...
@400000003c04e54013b255e4 status: exiting
@400000003c04e5a9160dd214 status: local 0/10 remote 0/20
@400000003c05323824b00d3c status: exiting
@400000003c05323928e33f3c status: local 0/10 remote 0/20
@400000003c053bb8200351f4 status: exiting
@400000003c053bbd13c45b2c status: local 0/10 remote 0/20

Then restarted qmail with no errors...



Can someone tell me if these questions are on the right track for troubleshooting?

Here goes:

1.  Is something preventing the external smtpd from binding the port?  
2.  Is there a stray ipchain rule that is blocking it?
3.  What log entries would be most helpful helpful to investigate for either of the above?
4.  Are there verbose logging modes that should be enabled to get me better information?

Any insights appreciated.

Dan

[Dan G.]

UPDATED:

I entered '/sbin/ipchains -n -L input' on the primary mail server and the test box, and the ipchains are slightly different.  Notably, the rule to ACCEPT port 25 is missing on the primary.  That explains why mail does not come thru.  

What I can't explain is this:  I enter the ipchains commands I find in 45AllowSMTP --

/sbin/ipchains --append input -p tcp -s 0/0 -d $OUTERNET 25 -j ACCEPT
   
/sbin/ipchains --append output ! -y -p tcp -d 0/0 -s $OUTERNET 25 -j ACCEPT

...and then do '/sbin/ipchains -n -L input'  again --- the changes are NOT updated in the rules displayed.  

I noticed this behavior while I was attempting to configure IPSec passthru using ipportfw inititally, and by following the instructions in http://forums.contribs.org/index.php?topic=1855.msg6169#msg6169 --- but I scrapped both of those efforts, and gave up on VPN for now.

What might be preventing the ipchains rules from being read correctly?  What prevents them from engaging when invoked directly from the command line?

TIA,

Dan