CPANEL stores the LOCAL emils and doesnot forward to MX

Webiz

Registered
Oct 3, 2002
4
0
151
Hi..

here is my problem :

i have MX record to : (mail.other-mserver.com ) for example

ok, when every my scripts on my domain sends emails to : [email protected] , it's stored *only* in the local inbox of the CPANEL...but it never forward them to the MX recorg i use ..

Example :

the VB script send email confirming new replies, if the email of the user is : ( [email protected] ) then this email will *not* be forwarded to the MX record i use , it's just stored in a local inboz of the CPANEL that only me can access it with (Harode) or (NeoMail) from the CP.

in the other side, if the email is set to ( [email protected] ) then the email is forwarded normally and is not stored in the local inbox..

i had this problem on 4 completly deffrent hosting servers, and had lot's of freids suffering from the same thing !

can any body please help me to solve this issue.

thanx allot :)
 

anand

Well-Known Member
Nov 11, 2002
1,432
1
168
India
cPanel Access Level
DataCenter Provider
i confirm the error. I noticed the same error on my server as well.

regards,

Anand
 

anand

Well-Known Member
Nov 11, 2002
1,432
1
168
India
cPanel Access Level
DataCenter Provider
An update from cpanel/whm news:

Fixups Changing the MX entry for a domain now removes/adds it from/to /etc/localdomains as needed.

(5.3.0 build 42 EDGE or later only)

This should help, i am yet to checkup.

regards,

Anand
 

Webiz

Registered
Oct 3, 2002
4
0
151
thanx anand for your reply..

but does this mean that i have to wait till my hosting server make the update, or they should do specific changes ?

regards.
 

anand

Well-Known Member
Nov 11, 2002
1,432
1
168
India
cPanel Access Level
DataCenter Provider
[quote:7b48d3d36f][i:7b48d3d36f]Originally posted by Webiz[/i:7b48d3d36f]

thanx anand for your reply..

but does this mean that i have to wait till my hosting server make the update, or they should do specific changes ?

regards.[/quote:7b48d3d36f]

Yes you need to wait for your hosting server to make the updates, also this update as stated is included in the bleading edge version which lots of servers don't update unless its in a stable form. However i run the bleeding edge version on my box.

I just updated the whm and this is what i found by using mail -v [email protected] where domain.com had its MX entry set to another server.

Now the mail program still delivered the mail to the local mailbox. I think nick still needs to look in this matter. But since this update has come inside the bleeding edge version, it shouldn't be much time once it is tweked up and is released inside the stable release.

regards,

Anand
 

bmcpanel

Well-Known Member
Jun 1, 2002
544
0
316
I think this is a normal process of sendmail (PHP, CGI, etc uses sendmail). Sendmail looks locally to find a FQDN and when it does find the domain on the same server as the form, it does not look externally and thus, the DNS MX record does not come into play. (I could be wrong but this is what seems to be happening).

To work around this, I did the following.

Server A
-- Origin domain name exists here with a PHP form, as an example. (Origin Domain: www.serverA.com)
-- The mx record directs mail to an exchange server that is NOT located on this server.
-- I want to receive form results as &[email protected]&.

Server B
On a completely different server, I setup an email account simply to receive form results from www.serverA.com (Example Email: &[email protected]&). I then forward the email back to &[email protected]&.

This is what happens...
1. In the form on serverA, I put the email address in the form to which I want to send the form results. I send the email results to &[email protected]&.
2. The email is sent to serverB and then forwarded to email address &[email protected]&.
3. The mx record on serverA.com then properly routes the mail to the custom mx address

I hope I have explained that properly. Basically, the form on serverA will only deliver locally and will ignore the custom MX record if the target email address is [email protected]. Thus, you have to send the email to another server that does not have serverA.com listed on it. Then, forward it back to serverA.com. By doing this, you put the custom mx record in play and the form results are forwarded to the correct destination address according to the custom mx record.
 

Webiz

Registered
Oct 3, 2002
4
0
151
hi..

thanx for the tip..

but unfourtnatly it's not practical when u are dealing with huge users or a free web-mail service...

i'm useing the site : www.gawab.com to have a free webmail at the domain name of my site..

so i think the developers -of CPANEL- should look about this issue.. and i don't think it's that hard to be fixed with some coding..

regards.
 

mohamed_gaber

Member
Mar 4, 2003
16
0
151
i have this problem..

i'm a reseller on a WHM/cPanel 6 ... and this problem is driving my clients crazy...

can any body help out please ?!!
 

Annette

Well-Known Member
PartnerNOC
Aug 12, 2001
445
0
316
Delivering mail from the local server to an external mail server.

1. Make sure your local zones are set to use the remote MX for the domain. If they use mail.theirdomain.com, make sure you adjust the mail CNAME to an A record with the appropriate IP.
2. Remove the domain's entries from /etc/userdomains and /etc/localdomains

That's all it takes to get the server to deliver mail offnetwork when an account is utilizing a third party mail server. Systems will look locally to deliver mail before looking elsewhere, and if the items in number two above exist, it will push mail to the user's account on the server instead of looking outside its realm.

If you're a reseller, you'll need to get your host to remove the /etc/*domains entries, as that takes root access. Depending on your zone editing permissions, they may need to make that change for you as well.
 

mohamed_gaber

Member
Mar 4, 2003
16
0
151
Originally posted by Annette
1. Make sure your local zones are set to use the remote MX for the domain. If they use mail.theirdomain.com, make sure you adjust the mail CNAME to an A record with the appropriate IP.
thanx allot Annette for your reply, but can u please explane to me that point, coz i got confused..

let's say :

* my domain name is : cpanoz.com
* my external mail server is : mail.pipoz.com

so i change the MX record to point to mail.pipoz.com
do i need some thing else ?

i can edit my DNS records from the WHM, and for the /etc/ i'll ask my hosting comp. to make it for me..

thanx again.
 

Annette

Well-Known Member
PartnerNOC
Aug 12, 2001
445
0
316
What you can do is edit your zone to point the MX record to mail.pipoz.com:

cpanoz.com. IN MX 0 mail.pipoz.com.

If you don't alter the mail CNAME entry, it will just act as a general subdomain of your account - if you don't intend to use mail.cpanoz.com for your mail, it can be left alone (or deleted, or changed) at your preference. Then have the host remove the other entries, send a test through the machine, and that will do it.
 

MarlboroMan

Well-Known Member
Dec 7, 2001
64
0
306
A further note - removing the domain from /etc/localdomains isn't a permanent fix, because if anyone runs /scripts/mailperm, it gets added right back. UNLESS the domain is listed in /etc/remotedomains. The mailperm script doesn't re-add domain names in /etc/remotedomains back to /etc/localdomains

Just FYI
 

Annette

Well-Known Member
PartnerNOC
Aug 12, 2001
445
0
316
It isn't a problem in the script per se. This is the way systems are designed to work (look local, then look elsewhere). It's up to the system admin to finalize the process if default values won't be used. With the exception of the initial mail structure changes in cPanel v5, the /scripts/mailperm we've only seen run during server to server transfers - we've never run it ourselves and removing the entries from the two main *domains files works without a problem. Of course, if you introduce more steps in what you do, the chance arises that you'll have to compensate for that. In the end, though, using remote mail servers is a piece of cake and the required changes are no big deal.