On Fri, 2006-04-21 at 23:32 -0400, Debbie Deutsch wrote: > Alastair Neil wrote: > > Did you check hosts.allow and hosts.deny in /etc? > > > > > > Thanks for the suggestion. I am still somewhat noobish and those files > were new to me. Thanks for teaching me. :-) > > Both files had only comments. They were not the source of the problem. > > However, I may have some progress to report. I can now successfully > telnet to my system and (by hand) send mail to an account there. > Hooray! I am not certain what fixed that. I did reboot after sending > my email. Maybe something got reset. > > OTOH, external (outside of my LAN) mail servers are still not connecting > to my server to send mail to the email address I have been using for > testing. I now am wondering if the problem is/was with DNS. My local > configuration is okay, but I am embarrassed to say that I just > discovered that I had never entered an MX record where I have that > domain publically hosted. (The previous incarnation of my mail server > was using a different domain.) Now to wait for the new MX record to > propigate and see if that will do the trick! A check of the maillog > shows that the server certainly is getting connections from spammers > attempting to send their trash to old domain. ---- A lot of residential bandwidth providers block smtp port traffic except to their prescribed smtp servers which means you can't host a normal mail domain on that type of connection for inbound mail and you must use a their smtp server as a smarthost setup for outbound mail. You are not specific with your problem or the machine in question so we have to deal with it on a theoretical level but if a system off lan can't connect to your smtp system, then the likely problems are firewall blocking smtp port on external access, or not forwarding if the firewall is a separate system, or that your bandwidth provider is simply blocking the traffic from getting through. There are some less likely causes such as sendmail MTA being deaf to external interface (like you appear to have fixed already), bad routing on the mail server and perhaps some others. Having the mx record set properly for your domain will be an issue for mail delivery but you can/should test using telnet from remote location which doesn't require dns to be functional or 'propagated' Craig
