clean install - own gmail mail is blocked

V

vinzzz

Verified User
Joined
Jun 7, 2017
Messages
11
Hi there,

I'm new to this forum, so forgive me if this isn't the correct subforum.

I have done several clean re-installs on my centos server with directadmin and I have the following installed:
Apache 2.4.18
DirectAdmin 1.50.0
Exim 4.83
dovecot 2.2.21

I've set up the admin account with dkim and spf and nameservers etc, and added a user lvl domain for that admin server.com
I created an email account for that user, lets say [email protected] and it works like a charm. I get a 10/10 score, I can send and receive mails from or to all kinds of other emailaccounts.

Then I added a new user through a reseller account with domain example.com. I've set it up like I used to do and get a 9 or 10/10 score as well for its created mail account [email protected].

Only problem is: my customer and me have tested before on this server, and we both have an old emailaccount set up in our phones. But that emailaddress doesnt exist anymore on the server (due to the re-installs). Some how, my customer and me can't send e-mails from our gmail accounts to [email protected]. My guess is due to the continues retries of our phones and thus our IP's to the server, we got blocked.

I've asked some friends if they could email to [email protected] from their gmail accounts and its working perfectly.

I cannot explain why my customer and I myself, cant send emails from our own gmail accounts to [email protected].

The odd thing? We CAN send from gmail to [email protected], but not to [email protected]. It is as if there was some kind of blocking or spam, but it is just a clean install, no plugins, no spamassassin enabled, no csf whatsoever.

After a few hours the e-mails from my gmail account start coming in my roundcube. But they are marked as deleted (not in spam folder, just in inbox).

Does anyone know what is going on? Does DA have some kind of spamfilter out of the box?
 
Thanks for replying!

The email sent from my own gmail account is nowhere to be found in any of the logs. It is as if there was a IP block or spam block for that particular emailaddress in a clean direct admin install.
I've seen the link you've provided before, but it states the options one has for installing extra modules for spam fighting. For me, its a clean install, so nothing in spam filters or whatsoever. Thats the odd thing!
After a day or maybe two, everything started to work. I've rebooted my server several times in that periode, so it's not due to a single reboot...

If I had CSF installed than I can imagine that my IP and that from my client would be blocked because of the continues failures to login to a non existing emailaddress on the server...
 
It's good to know that everything started to work. If you send emails from Gmail and they never reach your server it makes the things more complex for investigation without seeing logs. Have you ever had bounces in Gmail?

As for "clean directadmin install"... What is it? :) There are so many options to select at an installation time so hardly can I guess what you have there... unless you install it yourself using all the suggested defaults.

And even though RBL as far as I know enabled by default. So you need to check

Code: 
./build options

to see what you have there installed. Still it's optional and won't give many answers.
 
yeah my bad. I've re-installed it with the option my hostingcompany TransIP provides. It's called CENTOS + DIRECTADMIN haha, so nothing pointed out to what is default installed.

I've noticed RBL as well and tried with it enabled and disabled, no change.

./build options says
-bash: /build: No such file or directory
 
Yes, TransIP have their own template for VPS with Directadmin.

The command should be executed in /usr/local/directadmin/custombuild/ (changing path to it might be omitted here on the forums), so the full would be:

Code: 
cd /usr/local/directadmin/custombuild/
./build options

Anyway I'd rather think it was a DNS related issue. You added a new domain and it could take some time for DNS to get updated and propagated. Still would think of bounces.
 
Well I've thought of DNS too, but... everyone else could perfectly mail the emailaccount. Just not us two. But it was temporarily.

Apache: 2.4.18
mod_ruid2: 0.9.8
ModSecurity: no
Dovecot: 2.2.21
Dovecot configuration: no
AWstats: no
Exim: no
exim.conf update: no
BlockCracking: no
Easy Spam Fighter: no
SpamAssassin: 3.4.1
ClamAV: no
MySQL: no
MySQL backup: yes
PHP: 5.5
ProFTPD: no
Pure-FTPd: 1.0.42
Roundcube Webmail: 1.1.4
Run 'clean' every time: yes
Run 'clean_old_webapps' every time: yes
Run 'clean_old_tarballs' every time: yes
Show texts in bold: yes
Rest no

Does this give you any insight?

Maybe in the future the best way to handle is to indeed install CSF right away and set it all open (while testing) ?
 
Well

Code: 
AWstats: no
Exim: no
exim.conf update: no
BlockCracking: no
Easy Spam Fighter: no
SpamAssassin: 3.4.1

does not necessary mean that those options are not enabled as exim.conf update is set to no. But In case of TransIP I'm rather sure that Easy Spam Fighter is really disabled.

My wild guess: Gmail is big enough, and it probably could be so that you and your friends were sending emails from different outgoing SMTP nodes (Google have many SMTPs actually), and it can be so that they use decentralized DNS resolvers (guess needs to be checked)... hence the difference in behavior.

Hardly CSF could change things much. Unless some Google's outgoing IPs were banned with a firewall on your server, and in this case CSF/LFD would be more informative as it writes logs.
 
You must log in or register to reply here.
Back
Top