PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Computer/Internet Issues & Troubleshooting (https://www.pprune.org/computer-internet-issues-troubleshooting-46/)
-   -   Sun RaQ3 Cobalt - Sendmail Config Problems (https://www.pprune.org/computer-internet-issues-troubleshooting/241922-sun-raq3-cobalt-sendmail-config-problems.html)

LD Max 1st Sep 2006 23:29

Sun RaQ3 Cobalt - Sendmail Config Problems
 
Help please!!
For anyone not familiar with the RaQ3 it is a fairly old type of rackmounted server which runs on Linux. It provides Web (apache), e-mail (sendmail 8.9.3) and DNS services for multiple virtual domains (or virtual hosting).
Mails sent from local network (to which RaQ is connected) via any existing account to: user(at)deleteddomain.com are returned by the RaQ SMTP server with the following error:

The original message was received at Sat, 26 Aug 2006 19:13:22 -0400 from My ISP [XX.XX.XXX.XX] (may be forged)
----- The following addresses had permanent fatal errors ----- <[email protected]>
----- Transcript of session follows -----
554 MX list for deleteddomain.com points back to www.myserver.com
554 <[email protected]>... Local configuration error
Upon examining the root, I discovered the "/etc/sendmail.cw" file contains a list of domains which sendmail regards as its own and attempts local delivery for. The sendmail.cw file contained maybe 20 entries (including deleted domains and their host varients like www. and mail.). Bearing in mind I'm only hosting 3 domains now, it reads like a history list.
Sendmail documentation which I've read elsewhere suggests adding locally hosted domains to this file - to prevent the error described above - and conversely to remove entries for which local delivery is not required.
After manually editing the file and restarting sendmail, unfortunately it simply replaced my edited sendmail.cw file with the previous data. ALL the old domains reappeared in the file - BUT they don't appear anymore in the admin web interface (GUI).
There is also another file called: "/etc/virtusertable". The header of this file says it is automatically generated but to put any additions at the end. Scanning through this file the first section lists every possible combination of aliases mapped to usernames. These are all correct.
The next section starts:

Originally Posted by /etc/virtusertable
# accept-email-at-domain routes
(list in the following format)
@domain %[email protected]
@mail.domain %[email protected]
@mail.domain %1@www
(etc etc...)

However, this section includes all current AND deleted domains.
The last section of the file entitled "catch-all aliases" just lists the domains which are currently hosted.
I must take it these automatically generated files are gathering their information from the admin web interface GUI wizard. Clearly the GUI is not deleting domains cleanly in all the sendmail files, but hiding that fact when viewing the e-mail configuration through the web admin interface.
So now I'm really stumped for ideas!
Any help appreciated.

LD Max 3rd Sep 2006 00:06

anybody? :{

tallsandwich 15th Sep 2006 20:31

Have you checked the configuration of your DNS Resolvers?
 
So, sendmail is the blackest of all black arts and the configuration is designed to confise you. I HATE sendmail as it is sooo confusing and my small mind gets overloaded. I don't know your level of knowledge so forgive me if I teach you how to suck eggs here or I tell you something that is not 100% correct, but here goes:

The error message mentions an MX record that performs the redirect and that delivery fails. This means that the server to which the MX record points does not exist in DNS, or it is not running an SMTP server, or that this server is actually a local alias to your server?

Assuming that your machine is unix-like (you say linux?) then check the /etc/nsswitch.conf file (or equiv) to see what the entry for 'hosts' says. If it mentions 'dns' then sendmail may be using the MX records in your local DNS servers to decide on how to route the emails.

Check the /etc/resolv.conf (or equiv) and find out where the DNS servers in use are. If they are on your machine (you say it does DNS services) or a machine that you are in control of then have a look at the MX records - these are DNS entries used to decide on how to convert an SMTP mail domain name to a DNS domain name (I think it is that but welcome a more accurate description!?).

It looks like your DNS servers have an MX record that tries to route mails coming from the users of your sendmail instance, when they send any mails to deleteddomain.com, to the mail server at www.myserver.com.

I ASSUME (I try to avoid sendmail so know very little about all the files you mentioned) that there is a problem with contacting a mailserver at www.myserver.com, or that the nslookup for this name fails or the IP address for this name does not respond or that www.myserver.com is actually a name that resolves locally and therefore your sendmail application should accept mails to this domain but it does not.

?

tallsandwich 15th Sep 2006 20:37

Never seen a Sun RaQ3 Cobalt
 
Alternatively, if your machine really is as beautiful as this
http://spinel.sytes.net/~bibou/image/raq.jpg
then just ignore your email errors and sit back with a cup of tea and admire your server :)

tallsandwich 15th Sep 2006 20:59

Embarassed about MX records
 
So I was worried I did not know "exactly" how MX records are used so I looked em up:

http://en.wikipedia.org/wiki/MX_Record

This should help you figure out your routing problems, you seem to have been looking the the SMTP server's configuration to find the problem when the root cause appears to be related to an entry in the DNS configuration available to your SMTP server.

For the sake of argument:
"SMTP Server"="mail agent"="mail server"=sendmail process.

...and just in case for some reason your /etc/hosts file is being used in this process, check there are no entries in it that refer to deleteddomain.com and www.myserver.com.


All times are GMT. The time now is 16:38.


Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.