virtual_localdelivery and fake domain

P

pielciu

Verified User
Joined
Aug 27, 2008
Messages
16
Hello,

Just came across a serious problem. Spamblocker should do delivery tests in a different way. If I want to make a prank I can add domain to my CP called ex. gmail.com, setup email account to prank@gmail.com so no one will be able to send emails to a real prank@gmail.com account located on gmail.com servers!!!

It is treated by the server as virtual_localdelivery!

The only possible solution I can see to that, is to set up a script to check if domain is really hosted on our server + NS? and MX? record checks. Saying that, can't run it after domain is created as we need time for DNS records to refresh.

Any other solution?
Shall I start with the script thou? :P

Regards
 
Well, I can't see any real and stable solution to this problem.

If you check the nameserver records at the TLD official nameservers, there always are those registrar that won't let you set nameserver records for your domain without them being ready to go... so it makes it impossibile to do both.
If you check the MX record it's a similar problem -- a sysadmin should [be allowed to] setup the new hosting before removing the zone from the old hosting...

I guess that this is one of the many gaps of a shared server -- you have to trust everyone.
 
Yeap, sysadmin can do that, but not when you're trying to automate things for you. Guess I will end up with a script that at least informs me about a (possible?) fake domain....
 
A warning is better then nothing, if you integrate both checks (MX's and authoritative NS's) I guess there will be many hosters using your script.
 
You can use that pre install check thing I think.

http://help.directadmin.com/item.php?id=203


Something like the following lol :P

Code: 
#!/usr/bin/php

<?

$invaliddomains = array('ebay.com', 'yahoo.com', 'gmail.com');
$domain = getenv("domain");

if (in_array($domain, $invaliddomains)) {
die('You cannot create $domain it is reserved!');
}

?>
 
Last edited:
pielciu said:
Just came across a serious problem. Spamblocker should do delivery tests in a different way.
Click to expand...
Tell me how. Or rewrite it yourself and donate it to the community so I can retire :).
The only possible solution I can see to that, is to set up a script to check if domain is really hosted on our server + NS? and MX? record checks. Saying that, can't run it after domain is created as we need time for DNS records to refresh.
Click to expand...
Can't run it at all. Because it would prevent anyone setting up a domain on your server if it's already running somewhere else.

Jeff
 
jlasman said:
Tell me how. Or rewrite it yourself and donate it to the community so I can retire :).

Can't run it at all. Because it would prevent anyone setting up a domain on your server if it's already running somewhere else.

Jeff
Click to expand...

Whole my life I've been using postfix, so exim and spamblocker conf is new thing to me :/ ....same as DA.

I did not say I'm going to block it, just inform about possible situation...
 
I've been doing a lot of thinking about this. I still can't think of a solution that would allow users to set up a live domain so they can move it to a DirectAdmin server, and yet prevent unwanted duplicates. The only thing I can come up with is a list, but I don't like that.

Jeff
 
Well, like I said a warning is better than nothing. Instead of blocking the procedure, the script should just send a warning message to the reseller, or create a ticket for the reseller when an already existing domain is added. This way it's up to the reseller to check if the domain really belongs to the user.
 
I guess whether you'd want this or not would depend on whether or not most of your users are moving from other webhosts, or whether they're brand new.

Resellers already get an email when a new account is opened.

How about other input? What do other readers think?

Jeff
 
If I remember correctly the original poster wanted DirectAdmin to actually look up domains on the 'net and if they exixted, not allow the creation. The problem of course is in moving active domains to your server.

I much prefer this approach.

Jeff
 
You must log in or register to reply here.
Back
Top