External mail for local domains?

[Real-Hosts]

Hi folks,

Got a problem.
A client of ours is using DirectAdmin (way to go!) and they have setup the domain (only thing changed/added will be MySQL and the website public_html files - default email accounts, whatever they may be, are there) and DNS MX records for the domain(s) point to an external mail system they have setup elsewhere.

The problem is that on their site, they have several form submissions, which use the php mail() function to send emails to <staff name>@domain but the domain resides on the webserver, but the email doesnt.

Email doesn't get sent out.
I believe it's being tied up (routed locally, but accounts dont exist, so are blackholing) and therefore are being forced to use Hotmail addresses to recieve form submissions.

What is the way round this?
So that the server realises it's not dealing with the domain mail locally, and sends it to the right server (in this case, the MX record or otherwise a static setting)

Help :confused:

Thanks,
Joel.

[xemaps]

For a valid php mail, domain has to send mail with a real enveloppe, and depends to safe mode or not, parameters are not the same in mail function => you cannot force with safe mode on.
You can see with the web host to create a valid mail sender.

Off course add spf to the domain/ip allowed to send mail, on your da server (TXT in DNS).

But you can use mail smtp class with socket if allowed, this is the best solution if it doesn't work.

And sure, you can host the web to avoid all these problem.

[Real-Hosts]

I'm sorry,
I didn't understand that.

The customer has a dedicated server with us, but they have pointed their domains MX records to an external mail server (they own both). But when using PHP Mail() the emails don't leave the server, it appears to be handled locally, and therefore, blackholed.

So you're saying SMTP to a 3rd party (or that actual mail server - ie: the correct MX record) itself would be a better bet? This is what I thought, but wondered if theres anyway to remove the domain EMAIL HANDLING from DA only... So it doesnt route locally, but will seek to track down the MX record, and forward it?

Thanks.

[xemaps]

Sorry if you don't understand, english is not my best language.

Using smtp class is not 3rd party service, this is only a free code which can use your smtp by login as a right domain user. This avoid this situation.

If email are blocked localy, there is a problem on the php host. Possible it does not respect RFC, and/or you block them.

You can always install a form on your DA host.

[Real-Hosts]

Well,
It's a standard setup. SPF records aren't configured, as they aren't mandatory anyway, and alot of services still don't use them widely to make them effective.

I think the best way would be to use an SMTP class. I'll let their webdesigner know, so he can switch it.

[xemaps]

In all case, i encourage you to use SPF (TXT entry in DNS)
gmail use spf record...
http://www.openspf.org/wizard.html
easy to do.

[Real-Hosts]

But how will the SPF records help the mail be routed out, instead of routed locally?

I'm all up for the SPF records (although not mandatory) and what it's trying to do, so I will make a move to comply to that standard, just the internally routed (thus lost) mail is a pain in the butt.

[xemaps]

The recipient server, even relay, can check SPF from allowed sender smtp.
For lost mail see as i said with the php host.

[Real-Hosts]

I know it's the PHP Mail()
But the question is.. What do I change? It's a standard DirectAdmin installation. Nothing is custom.

[xemaps]

so the best is to use smtp class on php server, right ?

[Real-Hosts]

Thats my conclusion too :(

But was wondering if there was any way at all to edit config files etc, and make it recognise it as a non-local domain, even though its added into DA.

Ah well :(

Thanks for the help.

[xemaps]

i have myself 2 external web server
- on one domain no problem since i created the mail corresponding to like webmaster@domain.tld
- on another no problem it is added by spf but it stay a foreign adress

can't help more, just share.

[dirko]

Originally posted by Real-Hosts

But was wondering if there was any way at all to edit config files etc, and make it recognise it as a non-local MAIL domain, even though its added into DA.


actually i have the same problem with a mailer written in php.
if user signs in by a local account -domain resides on the freeBSD server- he gets his newsletter.
php ini writes: $mailserver = 'localhost';
In the php.ini "sendmail" is greyed out.

however, when a user with his account on a remote mailserver (A-MX-SPF etc all set, on the NS & in the DNS settings in DA, ) and tries to sign in, he gets on hold, not receiving his activation link.

Can this be solved in the settings somewhere?

dirko
hungary

[maxeq]

Originally posted by dirko
however, when a user with his account on a remote mailserver (A-MX-SPF etc all set, on the NS & in the DNS settings in DA, ) and tries to sign in, he gets on hold, not receiving his activation link.

Can this be solved in the settings somewhere?

Sorry to open up this topic again, but I'm having the same problem. User already has a website (example.com) and uses his e-mail address there to register for our hosting (someone@example.com). DirectAdmin seems to be trying to deliver the mail locally rather than to where the user's e-mail account is currently hosted.

Any config files I can change to force DirectAdmin to go out to DNS and lookup where to deliver the mail?

[dirko]

Originally posted by maxeq
Sorry to open up this topic again, but I'm having the same problem. User already has a website (example.com) and uses his e-mail address there to register for our hosting (someone@example.com). DirectAdmin seems to be trying to deliver the mail locally rather than to where the user's e-mail account is currently hosted.

Any config files I can change to force DirectAdmin to go out to DNS and lookup where to deliver the mail?

i think you should check your dns settings is in the A records there is an A record like "mail.domain.com" IP address so and so.
or a wild card. *.domain.com IP so and so.
that should solve the problemo.

rgds.
dirko
hungary
:p

[dirko]

PS: dont forget to fill in the right account in your outlook: pop.domain.com and smtp.domain.com .Sometimes it is better to put mail.domain.com for both pop3 and smtp.
If you run you own mailserver like argosoft it is much more easier.
regds.
dirko

[jlasman]

Originally posted by dirko
[B]i think you should check your dns settings is in the A records there is an A record like "mail.domain.com" IP address so and so.
or a wild card. *.domain.com IP so and so.
that should solve the problemo.
Nope. Even if you could make a change to the DNS zone before you sent the email, then you'd be stuck with wrong information in the zone file for the future.

And how would you know that you need to do it?

This solution is NOT a solution.

Jeff

[jlasman]

Originally posted by dirko
PS: dont forget to fill in the right account in your outlook: pop.domain.com and smtp.domain.com .Sometimes it is better to put mail.domain.com for both pop3 and smtp.[/quote
This is a nonsolution, since you're NOT the new user. And you can't change what runs on his desktop.
[quote]If you run you own mailserver like argosoft it is much more easier.
This is simply a non-sequiter; you cannot install anything on your new client's system. And installing this on your desktop won't resolve the problem.

Jeff

[jlasman]

There are two issues addressed in this thread.

The first issue is about using DA as the webserver and an offiste-mailserver. That's actually quite easy, and has been addressed in many posts in these forums.

Give the user the right to modify DNS, or do all of this for him.

From the user control panel click on MX Records. Uncheck Local Mail Server and save.

Then from the user control panel click on DNS Management. Create an A record for mail pointing to the IP# the user gave you for the offsite mailserver. Then delete the old A record; the one pointing to your server.

The second issue, how to stop people from using an email address from the domain they're in the midst of moving to your server, is quite a bit harder to resolve. And no matter what you'll do, you'll probably always have some issues with this.

First, here's a simple explanation of what happens and why:

DirectAdmin uses exim to send mail. Exim, like most servers, can either deliver email to a given domain using external or local delivery.

Once the domain is set up on the server, it uses local delivery which doesn't look up the domain in DNS, but rather delivers to it on the server.

So the user never gets the welcome email because it's delivered on the server.

You'd think the easy resolution would be to always use DNS lookups to deliver mail, but as I've discussed previously in these forums, that creates mail loops which cannot be resolved.

Here are several ways to resolve the problem:

Make sure whatever system you use to create users doesn't blindly deliver the welcome email to the local server. If you use ModernBill, or some similar program, to accept your orders, put it on it's own server (perhaps a VPS), and use it to deliver the emails rather than the server where the domain is being hosted.

If you're using your own solution, make sure to show (in large print, in capitals, in RED) on your page where you accept the email address, to not use an address in the same domain being moved to the server. And perhaps check for it in your code and return the customer to the same page rather than blindly accept the order.

If you set up domains by hand, send the customer his welcome email first, before you set up the domain, or write him using your ISPs mail server rather than the same one where you'll be setting up the account. Or perhaps (and really best practices anyway) write your customer and tell him/her you need an address you can use to reach him if his domain breaks for some reason, and wait for his/her response before you set up the account.

Jeff

[mo.mentum]

Hi. I've having the same issue. Local domain setup on DA, but mail server is external. MX record in DNS has been changed but DA still tries to delivery locally.

The solution provided (go to MX RECORD in user control panel) is no longer valid. I believe this option has been removed in more recent DA versions. Any alternatives? Do i just manually remove the domain from the /etc/virtual/domains list?

Regards.

[jlasman]

It has NOT been removed in any of our servers; we have the latest DirectAdmin installs.

However in order for it to be visible you need to have DNS control turned on for the reseller and for the user.

Jeff