Alexander has come to the conclusion, as I had, that the problem is not sendmail itself. He has been giving me substantial amounts of advice in email and has looked over some of my configs and thinks they are ok. During part of my debugging today, I decided to try procmail as well, and it suffers from the same problem. I can send mail, but not receive. I had tcpdump running all day, and could see Alexander trying to get to me. He would not get an immediate disconnect, but it seemed to timeout. During this time, my server was sending SYN,ACK pairs, but they apparently never got back to him.
The weird thing here, is that all web traffic works fine. Surely if there was a netmask problem of any sort, I would have the same problem - users would connect to one of my 4 or 5 virtual web servers running under apache, and not get anything back? All http traffic works fine, as do CGI script, Squirrelmail etc.
I'll try a few more ideas and post my findings when I get it working. It will be when, and not if!
Alexander deserves a public thanks for spending a LOT of time in emails with me trying to help resolve the problem, he gave me a lot of help, but as he said, remotely, it's very hard to diagnose a problem like this. Unfortnately, the weekend is almost over, and I have to go to work tomorro, so I'll try this again over the next few days.
From: Ron Herardian rherardi@gssnet.com Reply-To: For users of Fedora Core releases fedora-list@redhat.com To: For users of Fedora Core releases fedora-list@redhat.com Subject: Re: Fedora core 1 sendmail problems Date: Sun, 28 Mar 2004 19:03:17 -0800
In reviewing this thread it seems to me there could be an underlying network issue not related to the sendmail configuration, despite port forwarding for port 25 apparently working as before. Although the MTA is accepting connections from hosts on the local IP network (you can telnet to port 25 as Alexander reminded me) it may not be able to send a response to a host over the Internet.
As others have suggested, it's best to rule out network configuration problems, e.g., a wrong netmask or router setting that would not affect local traffic but that would break IP connections from remote networks. What you're observing might be produced, for example, if the route to the remote network were incorrect, i.e., your server gets the TCP connect via port redirection through your NetGear box and sends an ACK but the remote never gets it because the ACK never leaves the local network (routing problem, e.g., bad netmask).
What happens when you try to telnet from a remote host (not on your local network)? If the connection is dropped right away it would suggest that the originating host cannot get a connection on port 25. If the connection times out, e.g., after a few seconds, it would suggest a firewall or routing issue, i.e., packets are lost or discarded/dropped. I suspect you'll find the latter.
_________________________________________________________________ Get rid of annoying pop-up ads with the new MSN Toolbar FREE! http://toolbar.msn.com/go/onm00200414ave/direct/01/
Homer,
It's clear Mr. Dalloz is highly skilled and his contributions to this list are substantial. It seems the obvious possibilities may well have been exhausted as it is certainly true that an underlying network problem would affect other protocols. I have two thoughts that I hope may be useful.
1. There could be a firewall issue on the box itself, i.e., iptables is running and restricts port 25 to the local network. Just as a test try stopping iptables ("service iptables stop") and re-testing SMTP. [This may be the last 'obvious' possibility.]
2. Can you get SMTP to work inbound on any other machines on the same local network? If yes, the problem clearly is with the machine in question. If no, there is another problem such as another firewall or router that restricts port 25 (but not port 80). In the latter case, what does the rest of the network look like, e.g., a traceroute and physical topology?
If you're on one side of the linksys box and it provides NAT and port redirection and if the other side of the linksys box is a crossover cable to a cable modem or a DSL modem then you can interpose a simple 10 Base T hub, connect a machine to the outside network and take your traces from there. It may be interesting to compare the inside trace of the TCP port 25 connection attempt with the outside trace, although there would be PPPoE encapsulation on the outside network if I have described your configuration correctly.
Ron
Homer Sapions wrote:
Alexander has come to the conclusion, as I had, that the problem is not sendmail itself. He has been giving me substantial amounts of advice in email and has looked over some of my configs and thinks they are ok. During part of my debugging today, I decided to try procmail as well, and it suffers from the same problem. I can send mail, but not receive. I had tcpdump running all day, and could see Alexander trying to get to me. He would not get an immediate disconnect, but it seemed to timeout. During this time, my server was sending SYN,ACK pairs, but they apparently never got back to him.
The weird thing here, is that all web traffic works fine. Surely if there was a netmask problem of any sort, I would have the same problem - users would connect to one of my 4 or 5 virtual web servers running under apache, and not get anything back? All http traffic works fine, as do CGI script, Squirrelmail etc.
I'll try a few more ideas and post my findings when I get it working. It will be when, and not if!
Alexander deserves a public thanks for spending a LOT of time in emails with me trying to help resolve the problem, he gave me a lot of help, but as he said, remotely, it's very hard to diagnose a problem like this. Unfortnately, the weekend is almost over, and I have to go to work tomorro, so I'll try this again over the next few days.
From: Ron Herardian rherardi@gssnet.com Reply-To: For users of Fedora Core releases fedora-list@redhat.com To: For users of Fedora Core releases fedora-list@redhat.com Subject: Re: Fedora core 1 sendmail problems Date: Sun, 28 Mar 2004 19:03:17 -0800
In reviewing this thread it seems to me there could be an underlying network issue not related to the sendmail configuration, despite port forwarding for port 25 apparently working as before. Although the MTA is accepting connections from hosts on the local IP network (you can telnet to port 25 as Alexander reminded me) it may not be able to send a response to a host over the Internet.
As others have suggested, it's best to rule out network configuration problems, e.g., a wrong netmask or router setting that would not affect local traffic but that would break IP connections from remote networks. What you're observing might be produced, for example, if the route to the remote network were incorrect, i.e., your server gets the TCP connect via port redirection through your NetGear box and sends an ACK but the remote never gets it because the ACK never leaves the local network (routing problem, e.g., bad netmask).
What happens when you try to telnet from a remote host (not on your local network)? If the connection is dropped right away it would suggest that the originating host cannot get a connection on port 25. If the connection times out, e.g., after a few seconds, it would suggest a firewall or routing issue, i.e., packets are lost or discarded/dropped. I suspect you'll find the latter.
Get rid of annoying pop-up ads with the new MSN Toolbar FREE! http://toolbar.msn.com/go/onm00200414ave/direct/01/
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
Funny, When I read through the original posting by Homer, He said that he can send {port 25} but not receive {port 110} should he not be following your advice on port 110 unless he is receiving mail on 25. I have never seen a config like that though!
He should also try recreating the account on the server side. I had a case once where we just could not get the account to receive on the client side. Eventually I deleted the account on the server and recreated it.
Just a thought?
Cheers
On Mon, 2004-03-29 at 08:26, Ron Herardian wrote:
i.e., iptables is running and restricts port 25 to the local network. Just as a test try stopping iptables ("service iptables stop") and re-testing SMTP. [This may be the last 'obvious' possibility.]
Ron
Homer Sapions wrote:
. I can send mail, but not receive.
-
Chadley Wilson -
Homer Sapions -
Ron Herardian