Ok, I am at a loss here on what the problems is.

I can send mail from the web based email interface to external addresses and they go through fine.

I can also send a report from the CP to both internal and external email addresses.

I can retieve mail with eudora from mail.mydomain.com.

What I can't do is send mail via eudora using mail.mydomain.com or smtp.mydomain.com at all and I can not send mail from any external mail account to

any_address@any_domain.com

on my server... it bounces. The only think I can think of that I have not investigated yet is PMfirewall although I am certain I left the SMTP port open.

Any ideas anyone?

Rick

Start with /var/log/maillog

It should give you some clues.

I would be interested to hear what you find since I also use Eudora, but I use my ISPs SMTP server.

Another thing to check: did you enable mail relaying in Plesk? You'll either need it to be Open or Auth->SMTP. I _did_ read somewhere (I think at the Plesk forum) that PSA 2.0 and Auth->SMTP is broken for Eudora. Word is 2.5 will fix it, and 2.5 should be here _any_day_now_

-Danimal

Danimal,

Thank you for your reply. I looked at the maillog right off but it shows nothing but LOGIN/LOGOUT of the sysadmin. Nothing in there about attempts to connect externally.

I initially setup our relays as auth required with the pop login required before sending mail. Since then I have also tried removing the pop login requirement and even enabling open relays as well as white listing our static DSL IP... no progress or change so far.

Eudora error by the way...

Could not connect to "mail.edited.com"
Cause: connection refused (10061)

And I tried Outlook just to be sure... same results.

Rick

Interesting.

I got this same error with Eudora, but was able to get it to work with Outlook Express.

Question: did you try the following scenario?
- Relay completely open
- Outlook Express using your box as SMTP
- Send mail to external address

If so (it sounds like you did try this), what did you see in the logs?

If you _still_ saw nothing in your /var/log/maillog logs, then it seems to be a problem external to Qmail. Most likely a firewall problem or inetd/xinetd problem.

Are you running a firewall? If so, you have to be very particular about port 53... SMTP is a crazy beast (though not as bad as FTP). And particularly if you want to allow SMTP relaying on your machine. If you do have a firewall, check it's logs. Or, get set up to test the above scenario and bring down your firewall for a sec. Then test the scenario and see what happens. And then bring the firewall back up (of course).

Bottom line: it always comes down to eliminating variables. Debugging computer issues is the ultimate problem solving exercise!

Good luck! And feel free to post more info... we'll get this figured out eventually!

-Danimal

Outlook express gives a little more verbose description of the error...

The connection to the server has failed. Account: 'mail.x.com', Server: 'mail.x.com', Protocol: SMTP, Port: 25, Secure(SSL): No, Socket Error: 10061, Error Number: 0x800CCC0E

but it has the same end result, I can retrieve mail from the server but I can't send. Additionally all external mail sent to addresses on this server bounces with the error "Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)".

Some things I have tried is all variations of the relay settings, currently it is just set to open relay until this is corrected.

smtp.x.com and mail.x.com as the outgoing mail server in both clients (eudora and Outlook). BTW, smtp.x.com can't even be resolved so I don't think its a valid setting in any client program, at least for me.

Authentication setting in the clients is turned on and apparently working if I can retrive mail. Just to be sure I have tried disabling auth on both the server and client.

I can send mail internally via the webmail or report function to any internal or external address, the headers look fine.

Checking PMfirewall verified that ports 53 and 25 are open and unrestricted. I also tried stopping PMfirewall but that had no effect.

The maillog file is recording hits, I think I copy and pasted one of the default pre-setup logs by accident this morning when I looked at to. In any case, I see connection attempts from my IP but nothing looks unusual or obvious.

I notice that the Outlook error mentions an SSL switch on the smtp port. This is new to me, I don't think our version of Eudora has an option for this but Outlook does. I enabled SSL on outgoing mail through Outlook and the error changed to...

The connection to the server has failed. Account: 'mail.x.com', Server: 'mail.x.com', Protocol: SMTP, Port: 25, Secure(SSL): Yes, Socket Error: 10061, Error Number: 0x800CCC0E

so the error must not have anything to do with that. I am going to look into the inetd config next and see if things look in order.

Thanks again for your help.

Rick

Ric,

I'm seriously guessing that it's a firewall problem. Try bringing your firewall down so that all traffic is passed both in and out and then test a send in Outlook. It's normally not a good idea to bring your firewall down, but if you do it only for a moment, it probably will be okay. Another option would be to post your firewall rules so we can see if there is something strange going on.

So what I'd do:
- Get a message ready to send using mail.yourdomain.com as the SMTP server in Outlook Express
- Set the mail relay settings in Plesk PSA to Open (with no auth & no whitelist, for now)
- Open an SSH connection to your box and run: tail -f /var/log/maillog as root (this is to watch the Qmail messages
- Open another SSH connection and purge your firewall rules. I haven't used PMfirewall... does it provide a way to do this or is it only for generating rulesets? If the latter, you can just: /sbin/ipchains -F which will flush your ruleset.

NOTE: Do _not_ do this unless you are _sure_ your default inbound is ALLOW. If the default inbound is DENY then you'll lock yourself out _including_ your existing SSH connections
If you aren't sure, run: /sbin/ipchains -L -n |more The top line will say: Chain input (policy ACCEPT): or Chain input (policy DENY):

Anyway, assuming the policy is ACCEPT, you can flush the rules, and then...
- Send the message in Outlook Express. You should see the maillog messages about what is happening. Hopefully that will give you clues as to where things are broken
- Reload your firewall rules, either using PMfirewall or by hand (however you did it in the first place).

Now, if it works in this scenario (and it _should_), then the problem is with your firewall rules. If this is the case, I'd append -l to the end of some of your rules to try and track down which one is blocking. Another option is to read up on SMTP and ipchains. Here's a post that helped me:
http://lists.debian.org/debian-firewall/20...5/msg00163.html

If it's not your firewall, then I'd recommend contacting RS tech support, or contacting Plesk tech support.

Good luck!

-Danimal

I did try stopping PMfirewall and then sending mail. According to the command help this should have done it but I don't know if any settings remain in place after stopping.

There is a flush arg but it also restarts. Since it is loaded on boot I may have to uninstall/reinstall to completely disable it, I am not sure.

USAGE: pmfirewall [command]

COMMANDS:
start Enables PMFirewall.
stop Disables PMFirewall.
restart Flushes and reloads the rules in PMFirewall.
masqstart Enables IP Masquerading only (no firewall).
masqstop Disables IP Masquerading only (no firewall).
uninstall Completely removes PMFirewall.
help Displays this list of options.

There are actually 3 rule files associated with PMfirewall, I will list all 3 below. I will continue with your instructions, chain input policy is accept as well as output, forward policy is deny. I may have to uninstall PMfirewall and restart psa but it just takes a min to reinstall the firewall so no big deal.


pmfirewall.rules.1

#!/bin/sh
# pmfirewall.rules.1 used by pmfirewall package
#
#### Start Firewall ####

## Allow loopback interface
$IPCHAINS -A input -i lo -s 0/0 -d 0/0 -j ACCEPT
$IPCHAINS -A output -i lo -s 0/0 -d 0/0 -j ACCEPT

# Allow packets with ack bit set, they are from an established connection.
$IPCHAINS -A input ! -y -p tcp -s $REMOTENET -d $OUTERNET -j ACCEPT

# Block incoming IP Spoofing

# Turn on Source Address Verification

if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]
then
for f in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $f
done
fi

#Turn on SYN COOKIES PROTECTION (Thanks Holger!)
if [ -e /proc/sys/net/ipv4/tcp_syncookies ]
then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

# Now read pmfirewall.rules.local


and pmfirewall.rules.local

#!/bin/sh
# pmfirewall.rules.local
# ver.PM1 (do not remove this line)

### BEGIN SYSTEM DEFAULTS ###

# Block Nonroutable IP's from entering on the External Interface
$IPCHAINS -A input -j DENY -s 10.0.0.0/8 -d $OUTERNET -i $OUTERIF
$IPCHAINS -A input -j DENY -s 127.0.0.0/8 -d $OUTERNET -i $OUTERIF
$IPCHAINS -A input -j DENY -s 172.16.0.0/12 -d $OUTERNET -i $OUTERIF
$IPCHAINS -A input -j DENY -s 192.168.0.0/16 -d $OUTERNET -i $OUTERIF


# - Specific port blocks on the external interface -
# This section blocks off ports/services to the outside that have
# vulnerabilities. This will not affect the ability to use these services
# within your network.
#

# Back Orifice (logged)
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 31337 -j DENY -l
$IPCHAINS -A input -p udp -s $REMOTENET -d $OUTERNET 31337 -j DENY -l

# NetBus (logged)
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 12345:12346 -j DENY -l
$IPCHAINS -A input -p udp -s $REMOTENET -d $OUTERNET 12345:12346 -j DENY -l

# Trin00 (logged)
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 1524 -j DENY -l
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 27665 -j DENY -l
$IPCHAINS -A input -p udp -s $REMOTENET -d $OUTERNET 27444 -j DENY -l
$IPCHAINS -A input -p udp -s $REMOTENET -d $OUTERNET 31335 -j DENY -l

# Multicast
$IPCHAINS -A input -s 224.0.0.0/8 -d $REMOTENET -j DENY
$IPCHAINS -A input -s $REMOTENET -d 224.0.0.0/8 -j DENY


### END SYSTEM DEFAULTS ###


#### EXAMPLES ###


### ALLOWED NETWORKS
# Add in any rules to specifically allow connections from hosts/nets that
# would otherwise be blocked.
#$IPCHAINS -A input -s [trusted host/net] -d $OUTERNET -j ACCEPT

### BLOCKED NETWORKS
# Add in any rules to specifically block connections from hosts/nets that
# have been known to cause problems. These packets are logged.
#$IPCHAINS -A input -s [banned host/net] -d $OUTERNET -j DENY -l

### BLOCK ICMP ATTACKS
#
#$IPCHAINS -A input -b -i $OUTERIF -p icmp -s [host/net] -d $OUTERNET -j DENY -l


#### END OF EXAMPLES ###



### AUTOMATICALLY GENERATED BY THE INSTALL SCRIPT ###

#DHCP CLIENT BLOCK
$IPCHAINS -A input -p udp -s $REMOTENET -d $REMOTENET 67:68 -i $OUTERIF -j DENY
#FTP
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 20 -j ACCEPT
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 21 -j ACCEPT
#SSH
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 22 -j ACCEPT
#SMTP
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 25 -j ACCEPT
#DNS
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 53 -j ACCEPT
$IPCHAINS -A input -p udp -s $REMOTENET -d $OUTERNET 53 -j ACCEPT
#HTTPD
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 80 -j ACCEPT
#POP
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 110 -j ACCEPT
#IDENTD
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 113 -j ACCEPT
$IPCHAINS -A input -p udp -s $REMOTENET -d $OUTERNET 113 -j ACCEPT
#NTP
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 123 -j ACCEPT
$IPCHAINS -A input -p udp -s $REMOTENET -d $OUTERNET 123 -j ACCEPT
#NETBIOS
$IPCHAINS -A input -p tcp -s $REMOTENET -d $REMOTENET 137:139 -i $OUTERIF -j DENY
$IPCHAINS -A input -p udp -s $REMOTENET -d $REMOTENET 137:139 -i $OUTERIF -j DENY
#IMAP
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 143 -j ACCEPT
#SSL
$IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 443 -j ACCEPT
#RIP
$IPCHAINS -A input -p udp -s $REMOTENET -d $REMOTENET 520 -i $OUTERIF -j REJECT
#NFS
$IPCHAINS -A input -p tcp -s $REMOTENET -d $REMOTENET 2049 -i $OUTERIF -j DENY -l
$IPCHAINS -A input -p udp -s $REMOTENET -d $REMOTENET 2049 -i $OUTERIF -j DENY -l
#XSERVER
$IPCHAINS -A input -p tcp -s $REMOTENET -d $REMOTENET 5999:6003 -i $OUTERIF -j DENY
$IPCHAINS -A input -p udp -s $REMOTENET -d $REMOTENET 5999:6003 -i $OUTERIF -j DENY
#CUSTOM
$IPCHAINS -A input -p tcp -s $OUTERNET -d $REMOTENET 8443 -i $OUTERIF -j ACCEPT
$IPCHAINS -A input -p udp -s $OUTERNET -d $REMOTENET 8443 -i $OUTERIF -j ACCEPT
#CUSTOM
$IPCHAINS -A input -p tcp -s $OUTERNET -d $REMOTENET xxx(edited) -i $OUTERIF -j ACCEPT
$IPCHAINS -A input -p udp -s $OUTERNET -d $REMOTENET xxx(edited) -i $OUTERIF -j ACCEPT


and pmfirewall.rules.masq

#!/bin/sh
#pmfirewall.rules.masq - used by pmfirewall package
#

## Masquerading

## Modules to help certain services

/sbin/depmod -a >/dev/null 2>&1
/sbin/modprobe ip_masq_ftp >/dev/null 2>&1
/sbin/modprobe ip_masq_raudio >/dev/null 2>&1
/sbin/modprobe ip_masq_irc >/dev/null 2>&1
/sbin/modprobe ip_masq_icq >/dev/null 2>&1
/sbin/modprobe ip_masq_quake >/dev/null 2>&1
/sbin/modprobe ip_masq_user >/dev/null 2>&1
/sbin/modprobe ip_masq_vdolive >/dev/null 2>&1

## Masquerading firewall timeouts: tcp conns 8hrs, tcp after fin pkt 60s, udp 10min
$IPCHAINS -M -S 14400 60 600

## Set up kernel to enable IP masquerading
echo 1 > /proc/sys/net/ipv4/ip_forward

## Set up kernel to handle dynamic IP masquerading
echo 1 > /proc/sys/net/ipv4/ip_dynaddr

## Don't Masquerade internal-internal traffic
$IPCHAINS -A forward -s $INTERNALNET -d $INTERNALNET -j ACCEPT

## Don't Masquerade external interface direct
$IPCHAINS -A forward -s $OUTERNET -d $REMOTENET -j ACCEPT

## Masquerade all internal IP's going outside
$IPCHAINS -A forward -s $INTERNALNET -d $REMOTENET -j MASQ

## Set Default rule on MASQ chain to Deny
$IPCHAINS -P forward DENY

## Allow all connections from the network to the outside
$IPCHAINS -A input -s $INTERNALNET -d $REMOTENET -j ACCEPT
$IPCHAINS -A output -s $INTERNALNET -d $REMOTENET -j ACCEPT

# This section manipulates the Type Of Service (TOS) bits of the
# packet. For this to work, you must have CONFIG_IP_ROUTE_TOS enabled
# in your kernel

# Set telnet, www, smtp, pop3 and FTP for minimum delay
$IPCHAINS -A output -p tcp -d 0/0 80 -t 0x01 0x10
$IPCHAINS -A output -p tcp -d 0/0 22 -t 0x01 0x10
$IPCHAINS -A output -p tcp -d 0/0 23 -t 0x01 0x10
$IPCHAINS -A output -p tcp -d 0/0 21 -t 0x01 0x10
$IPCHAINS -A output -p tcp -d 0/0 110 -t 0x01 0x10
$IPCHAINS -A output -p tcp -d 0/0 25 -t 0x01 0x10

# Set ftp-data for maximum throughput
$IPCHAINS -A output -p tcp -d 0/0 20 -t 0x01 0x08

# Allow outgoing ICMP
$IPCHAINS -A output -p icmp -s $INTERNALNET -d $REMOTENET -j ACCEPT

I turned off firewall with /usr/local/pmfirewall/pmfirewall stop

flushed the ipchains with /sbin/ipchains -F

brought up a monitor on the maillog and recorded this...

Mar 5 18:32:46 plesk pop3d: Connection, ip=[my_dsl_ip]
Mar 5 18:32:46 plesk pop3d: LOGIN, user=domain1user, ip=[my_dsl_ip]
Mar 5 18:32:46 plesk pop3d: LOGOUT, user=domain1user, ip=[my_dsl_ip], top=0, retr=0

Mar 5 18:32:48 plesk pop3d: Connection, ip=[my_dsl_ip]
Mar 5 18:32:48 plesk pop3d: LOGIN, user=domain2user, ip=[my_dsl_ip]
Mar 5 18:32:48 plesk pop3d: LOGOUT, user=domain1user, ip=[my_dsl_ip], top=0, retr=0

That is two different mail accounts, one on an IP based domain and one on a namebased domain. Each of them tried to send an email and retrieve mail from the server. The sending failed and the retrieve worked on both accounts.

Before I bother RS on this I am going over to the Plesk forum to see if I can find any information there. Once again Danimal, thank you so much for your help and detailed instructions.

Rick

I see that Port 993 is left open as a second imap port in a post over here, that is the only port on the list which I have not enabled via the firewall. My list is as follows excluding a secret SSH port.

tcp ports (port number, service running):
21 ftp
22 SSH
25 SMTP
53 named
80 http
110 POP3
143 IMAP
443
3306
8443 plesk

Ric,

Ya got me stumped. You are certainly going about it the right way... tracking it down bit by bit.

The thing that still strikes me as odd is that you aren't showing any Qmail logs for the sending. Whenever I tried sending from my local email client using my RS box as the SMTP server, I got entries in both /var/log/maillog and /var/log/messages.

I just sent an email from Outlook Express to an external address using my RackShack box as the SMTP server. Here's my logs (IPs & names cleaned to protect the innocent )

From /var/log/messages:
-------------------------------------------------------------
Mar 5 22:45:43 rsbox authpsa: IMAP connect from @ []
Mar 5 22:46:32 rsbox smtp_auth: SMTP connect from unknown@ []
Mar 5 22:46:32 rsbox smtp_auth: smtp_auth: SMTP user dan : /usr/local/psa/qmail/mailnames//dan logged in from unknown@ []


From /var/log/maillog:
-------------------------------------------------------------
Mar 5 22:46:32 rsbox qmail: 1015386392.788977 new msg 33007
Mar 5 22:46:32 rsbox qmail: 1015386392.789143 info msg 33007: bytes 2584 from qp 8269 uid 2020
Mar 5 22:46:32 rsbox qmail: 1015386392.791636 starting delivery 3: msg 33007 to remote dan@
Mar 5 22:46:32 rsbox qmail: 1015386392.791770 status: local 0/10 remote 1/20
Mar 5 22:46:33 rsbox qmail: 1015386393.708930 delivery 3: success: 128.241.199.153_accepted_message./Remote_host_said:_250_OK_id=16iSNl-0001jg-00/
Mar 5 22:46:33 rsbox qmail: 1015386393.709097 status: local 0/10 remote 0/20
Mar 5 22:46:33 rsbox qmail: 1015386393.709114 end msg 33007

----------------------------------------------------
Lessee... I have Mail Relaying set to: "require authorization" with only SMTP checked. I've created the local domain and created the POP3 mail box "dan".

As for firewall rules, Maybe this will help (taken from "/sbin/ipchains -L -n"). I have two rules on my input chain:
ACCEPT tcp !y---- 0.0.0.0/0 25 -> 1024:65535
ACCEPT tcp ------ 0.0.0.0/0 * -> 25
and two rules on my output chain:
ACCEPT tcp ------ 0.0.0.0/0 1024:65535 -> 25
ACCEPT tcp ------ 0.0.0.0/0 25 -> *

These four rules let me handle SMTP relaying from external hosts as well as sending SMTP connections from my RS box to other hosts. It _looks_ like you have essentially the same thing.... perhaps even more open on port 25. I'd be interested to see what a dump of "/sbin/ipchains -L -n" for port 25 looks like with your ruleset.

Anyway, keep at it! I know it can work because I just did it myself. If you'd like to PM me with some specifics, I'd be glad to do some comparisons... maybe we can track down what is different between your setup and mine.

-Danimal

I would like to add those rules, do I have to add them into the pmfirewall.rules.local using the variable definition syntax contained in that file or is there a .conf file I can edit directly?

It looks like it would not hurt to add the rules but it probably isn't the cause of the problem. Am I correct in assuming that since the firewall was disabled and the rule set flushed, it eliminated ipchains as the problem?

I posted on the Plesk forum outlining the problem and what we have tried here. I didn't see anything exactly like my problem, I did see something about a hostname change that I was unaware of...

"If you are running your own DNS enter your IP's into the /etc/resolv.conf, if you are not leave the IP's that are there."

my resolv.conf file lists RS nameservers and says...

search rackshack.net
nameserver xxx.xxx.xxx.38
nameserver xxx.xxx.xxx.39

I tried changing these to our nameserver IP's but SQL would not start and it did not fix the mail problem so I changed it back.

When I find a solution I will post it here.

Rick

No answer in the Plesk forum yet. I have noticed a DNS issue that may or may not be realated to or causing this problem though. When I first bought this server we regged a .biz extention of another domain we have hosted elsewhere, the box was initially setup under this domain by RS and I intended to run our nameservers off the same domain.

As it turned out, the .biz TLD does not support nameservers and so we regged another .com domain for them. No problem, I added the domain (used one of our additional IP's for IP based hosting on this domain), added the nameservers (using two more of the additional IP's we aquired for NS) and after propagaion, everything seemed to be working ok. Everything except the original .biz domain which has never been able to resolve. All of our domains are pointed to the nameservers we installed, none are pointed at RS nameservers.

I did run linxconf and the reconfigurator to change the hostname when I first switched things over to the new .com domain we regged for the master domain account.

I then had to manually edit the qmail /control/me file to reflect this new hostname and I would have to look at my notes but I had to edit another file to make apache restart when I was all finished.

What is wierd and why I think it is related to this qmail problem is this. If I go to any domain in Plesk (IP or name based), go to the DNS page on that domain and use the on/off button to turn off the DNS zone and display the nameserver links, all of the nameserver links return this error...

*** Error : There is no DNS entry for your domain on this nameserver
*** : or this nameserver work incorrectly.

From the shell if I try nslookup mydomain.com it does resolve on every domain we have... except the original .biz domain.

In other words, a nslookup from shell on our primary domain which has its own IP and its own (2) nameserver IP's comes back to the IP that it is assigned to.

A nslookup from shell on any of our name based domains returns the master IP of the server.

A nslookup from shell on the original .biz domain has always returned...
** server can't find mydomain.biz.: NXDOMAIN

One last thing, when I initially changed the master domain on this box I set it up as name based hosting using the master server IP. I had to use one of our additional IP's and switch it over to IP based hosting before any of our domains would go live. No big deal because I wanted an SSL cert for that IP anyway but it is odd that I had to do it just to make the other domains on this box resolve.

To be clear, this is what the DNS zone of our primary domain looks like...

xxx.xxx.xxx. 66 is the server IP
xxx.xxx.xxx. 112 is NS1
xxx.xxx.xxx. 113 is NS2
xxx.xxx.xxx. 110 is the domain IP

mymaindomain. com. NS ns. mymaindomain. com
mymaindomain. com. NS ns1. mymaindomain. com
mymaindomain. com. NS ns2. mymaindomain. com
ns. mymaindomain. com. A xxx.xxx.xxx. 66
webmail. mymaindomain. com. A xxx.xxx.xxx. 66
ns1. mymaindomain. com. A xxx.xxx.xxx. 112
ns2. mymaindomain. com. A xxx.xxx.xxx. 113
mymaindomain. com. A xxx.xxx.xxx. 110
ftp. mymaindomain. com. CNAME mymaindomain. com
mail. mymaindomain. com. CNAME mymaindomain. com
www. mymaindomain. com. CNAME mymaindomain. com
mymaindomain. com. MX 10 mail. mymaindomain. com
xxx.xxx.xxx. 110/24 PTR mymaindomain. Com

This is what the DNS zone of our name based, hosted domain looks like...

hosteddomain. com. NS ns. hosteddomain. com
ns. hosteddomain. com. A xxx.xxx.xxx. 66
webmail. hosteddomain. com. A xxx.xxx.xxx. 66
hosteddomain. com. A xxx.xxx.xxx. 66
ftp. hosteddomain. com. CNAME hosteddomain. com
mail. hosteddomain. com. CNAME hosteddomain. com
www. hosteddomain. com. CNAME hosteddomain. com
hosteddomain. com. MX 10 mail. hosteddomain. com
xxx.xxx.xxx. 66/24 PTR hosteddomain. com

I don't know, maybe I am just grasping here. I really hate to email RS about this, not even sure if they will help me on it. Just in case this is the problem I am going to add this same information to my current post in the Plesk forum as well.

Rick

It looks like your hosted domain doesn't reference your nameservers.
You should have two lines (or three if you are using three nameservers) like:
hosteddomain.com. NS ns1.mymaindomain.com
hosteddomain.com. NS ns2.mymaindomain.com

As for emailing RS, I would certainly do it. The worst that happens is they say "sorry, can't help ya"... the best is that they solve it for you or offer you some new things to try.

When you are trying to troubleshoot a problem, the more advice the better (usually).

:-)

Keep at it!

-Danimal

P.S. Another thing: when I changed the name of my machine, I first ran linuxconf and then ran the Plesk reconfigurator (reconfigurator.sh). Those two changed everything for me, including the Qmail stuff .../control/me and the like. I _did_ have to reboot, though (still don't know why) to get the change to completely take hold.

I thought I might need to add the two nameservers manually to each domain but since they are all working via http, I had just left it alone for now.

I don't think that is the root problem because I have been running email tests from the master account too with the same results.

The reconfigurator changed everything except for the me file which just contains the hostname for the headers. Also I had to edit the FTP config file so the hostname was correct for the login message. Both of those were just cosmetic.

I updated my post in the Plesk forum and will wait until tonight before I write RS as a last resort. I still think it is wierd about the .biz domain not resolving and my gut feeling is that it is related to the root cause of the problem.

Rick

I am seeing a lot of posts on the Plesk board about changing the resolv.conf after a hostname and/or IP change on the main domain. What does your resolv.conf file say? Are your nameserver IP's listed or rackshacks?

my resolv.conf file lists RS nameservers and says...

search rackshack.net
nameserver xxx.xxx.xxx.38
nameserver xxx.xxx.xxx.39

This RS thread also talks about this and mentions a missing symlink... looks like a very similar problem.

http://forum.rackshack.net/showthread.php?...ght=resolv.conf

To stay current...

I did change my resolv.conf file to

File: /etc/resolv.conf

search mydomain.com
nameserver xxx.xxx.xxx.112
nameserver xxx.xxx.xxx.113

Rebooted and now my .biz extention resolves fine from a nslookup in the console just like the rest of our IP and name based domains.

So... although that may have been a problem and seems to now be corrected, our mail service problem still remains unchanged. I can only assume it is unrelated to the DNS issue. Since firewall has also been ruled out in yesterdays trouble shooting, I am at a loss as to what to try next.

I opened an RS trouble ticket and will await their reply, if they can't help I guess I will buy some phone support from Plesk.

Actually,

My /etc/resolv.conf just says:

nameserver 207.218.192.38
nameserver 207.218.192.39


I took out the search ... line per some post I saw here that suggested it.

The two IPs above are RackShack DNS servers that a RS tech support guy said we should be using (the .7 & .8 numbers are old, I believe)

-Danimal

P.S. Good luck with RS tech support. I really hope that they can help you resolve this. I feel your pain, but keep pressing on. You'll get it fixed one way or another!

Rick,

How's things going? Did you get this resolved? Did you have to resort to Plesk support? System restore?

Inquiring minds want to know.

-Danimal

Still fighting it, RS came back with "your config is ok" so I went to borders and picked up a book on Qmail. I will resort to plesk support if I have to but I would rather find the problem myself.

I have learned some stuff...

ps aux | grep qmail

[root@plesk control]# ps aux | grep qmail
qmails 14626 0.0 0.0 1456 388 pts/1 S 22:57 0:00 qmail-send
qmaill 14627 0.0 0.0 1412 468 pts/1 S 22:57 0:00 splogger qmail
root 14628 0.0 0.0 1404 312 pts/1 S 22:57 0:00 qmail-lspawn ./Ma
qmailr 14629 0.0 0.0 1400 308 pts/1 S 22:57 0:00 qmail-rspawn
qmailq 14630 0.0 0.0 1400 328 pts/1 S 22:57 0:00 qmail-clean
root 14649 0.0 0.1 1740 600 pts/1 R 23:02 0:00 grep qmail

Don't see smtp running there... should I? Seems like I should. Additionally...

netstat -nat

[root@plesk control]# netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 xxx.xxx.xxx.107:53 0.0.0.0:* LISTEN
tcp 0 0 xxx.xxx.xx.114:53 0.0.0.0:* LISTEN
tcp 0 0 xxx.xxx.xxx.113:53 0.0.0.0:* LISTEN
tcp 0 0 xxx.xxx.xxx.112:53 0.0.0.0:* LISTEN
tcp 0 0 xxx.xxx.xxx.60:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN
tcp 0 52 xxx.xxx.xxx.60:22 xxx.xxx.xxx.xxx:1347 ESTABLISHED

I don't see port 25 open and it is not disabled in the firewall...

The error on email client is "no socket" so I think I have found the problem.

The question is why isn't smtp running and how do I fix it?

I have seen some posts referring to a "softlink" (meaning symlink?) I am not sure what this means or how to check for it...

"ensure you have the right softlink in /usr/sbin it should be

sendmail -> /var/qmail/bin/sendmail"

Any ideas?

Rick

Getting closer.

Lessee...

I have the exact same output for the ps -aux | grep qmail command, so I think that's okay.

My netstat -nat _does_ show a line for port 25, so that would be a big red flag I'd think.

As for softlinks, what it means is (at least as I understand it)... Qmail replaces sendmail as the MTA agent handling SMTP and POP/IMAP traffic. But, to avoid screwing up other things, Plesk doesn't totally remove sendmail, instead it creates a symbolic link from:
/usr/sbin/sendmail -> /usr/local/psa/qmail/bin/sendmail
(at least that's how it is set up on my box). Plesk also copies the original /usr/sbin/sendmail program to /usr/sbin/sendmail.saved_by_psa

So probably, your system via either inetd or xinetd receives connections on port 25 and fires up the sendmail daemon, which because of the symlink above is actually the qmail "sendmail" program. This would explain why your ps -aux didn't show anything. It's the same with ProFTPd ("ps -aux | grep ftp" won't show anything unless a connection is currently active).

Given that you can send email via webmail, and that netstat isn't showing port 25 open, it might be an inetd/xinetd misconfiguration. How does your /etc/services file look? Were you tweaking with it for any reason?

You are definitely honing in on the problem, that's for sure. I'd focus on why netstat doesn't show port 25 as listening. That's the root of the problem... the only question is why is it not listening? (we've ruled out firewall issues, which leaves [x]inetd and/or qmail misconfigurations or something _really_ obscure).

Keep at it!

-Danimal

/etc/services - have not touched that file and looking at it I see the ports and alias for smtp are in place.

inetd/xinetd - unchanged

I thought that is what they meant about a soft link and it is in place so that can't be it.

That has to be a running process that listens on port 25, do you know what that module is? Can it be started by itself? Can I check to see if its started up with qmail? I don't see a verbose option on qmail so I am guessing no. There must be a config file that points to the various modules qmail loads on startup I would think.

Rick

According to this post...

http://forum.rackshack.net/showthread.php?...&highlight=smtp

"ps -aux | grep sendmail

You should see "sendmail: accepting connections on port 25" otherwise SMTP is not running"

I see...

[root@plesk xinetd.d]# ps -aux | grep sendmail
root 15383 0.0 0.1 1736 596 pts/1 R 02:01 0:00 grep sendmail

Just more confirmation that this is the problem, no solution listed in that post.

Rick

I don't show anything either with ps -aux | grep sendmail and it seems to be working on my end (remote emailing via RS SMTP)

Also, the suggestion in that thread was for RaQs, which may or may not use qmail (not sure, since I don't have a RaQ).

I found this... don't know if it helps, though:
http://www.qmail.org/qmail-manual-html/man...mail-smtpd.html

If I were you, I'd focus on why your netstat -nat does not show a listing for port 25. I don't know how to dig further, but that's where I'd start. My guess is: qmail is listening for incoming SMTP connections but on a different port (misconfigured), or qmail is simply not listening on port 25 (broken).

Wish I could help more! This is all new stuff to me too.



-Danimal

does your

/etc/mail/local-host-names

list your doamins? mine is empty and sendmail.cf loads them from this file.

Rick

Mine's empty too.

-Danimal

sendmail must not use any of the related config files listed in sendmail.cf

looks like all those variables are used by qmail from files in the
/usr/local/psa/qmail/control dir

if i run /usr/local/psa/qmail/bin/qmail-smtp...

[root@plesk /etc]# /usr/local/psa/qmail/bin/qmail-smtpd
220 plesk.x.com ESMTP

and look at netstat it shows two connections on port 110 waiting for input but does not open port 25 for listening.

my smtp_psa file looks ok...

service smtp
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
instances = UNLIMITED
server = /usr/local/psa/qmail/bin/tcp-env
server_args = /usr/local/psa/qmail/bin/relaylock
/usr/local/psa/qmail/bin/qmail-smtpd /usr/local/psa/qmail/bin/smtp_auth /usr/local/psa/qmail/bin/true /usr/local/psa/qmail/bin/cmd5checkpw /usr/local/psa/qmail/bin/true
}


or at least it matches the config I have seen in a few posts here to the letter. At one time I had addrd a -R to prevent reverse DNS lookups to server args but I have went back to the original file to rule it out from being a problem.

It _was_ my fault! Get this... Before I modified my smtp_psa file I created a backup named smtp_pas.bak which is a practice I have used for about twenty years now when working with system files.

Plesk was reading both files in and the conflict was disabling port 25. Being new to Linux I had no idea that renaming a file for backup by adding an extension could effect a running process, never heard of such a thing! I really have a lot to learn but this is one mistake I will not make again, temp backup files will get completely different names from now on.

I wish I could say that I solved this myself but I gave up and bought a per incident Plesk support session. The Plesk people are great by the way, they handled this via email and a couple faxes on a Saturday night!

They initially ran a few tests and told me my provider had port 25 closed (router or switch I assumed) and suggested I contact RS about it. I couldn't believe that RS had breezed through two TT's on the problem, told me everything was correct and then have it turn out to be a problem on thier end.

Well, RS responded promptly (on a Sunday) with thier own analysis which I took to Plesk techs who found the cause of the problem.

RS did everything right, they had looked at the problem specifically with the information I had given to them and had no reason to look for another obscure problem I had created elsewhere. Even in what must be a really busy state of business with the upcoming announcement, they still answered all TT's promptly and accurately.

So... problem solved, lesson learned. Thank you for all your help Danimal, I am sorry I put you through all this trouble shooting for nothing! Actually it was not for nothing, I learned a lot about IP chains and firewalls and Qmail and Plesk out of the deal but you probably got nothing but a headache! I guess I owe you one huh?

Rick

All right!

I'm glad you finally got it figured out! Isn't that always the way, though? You slog through days of hair-pulling trials-n-errors, only to discover it is something super simple or should-have-been-obvious!

Of course in this case, it seems like it is just a poorly written script. Scripts that automatically read all files in a directory as config files, regardless of how they are named, are poorly written scripts IMHO (with the possible exception of /etc/rc.d/ scripts).

Anyway, I truly hope that the rest of your dedicated-box journey is a whole heck of a lot easier than this stretch has been.

As my old man used to say: "never give up!" Good advice, and quite applicable in this case.

-Danimal