Quick setup of secondary E-mail server

dkurel

Verified User
Joined
Jan 6, 2007
Messages
12
Here is how I did it - hopefully someone else would find it useful.
It is based on the idea from this post.

I am asuming that you have the secondary server installed and Sendmail set up so that it listens on apropriate IP address(es).
By default - Sendmail listens only on 127.0.0.1 (at least on CentOS).

MASTER SERVER (Direct Admin):

Type this as root:

Code:
mkdir -p /var/www/html/secmail
ln -s /etc/virtual/domains /var/www/html/secmail/domains

SLAVE SERVER(I have CentOS 3.9 with Sendmail ClamAV and ClamAV milter, but it is up to you...)

1. Edit the file "/etc/mail/updatedomains.sh" and put this code in there:

Code:
#!/bin/sh
#
# This script updates domain list from  primary to the secondary E-mail server
#
cat /dev/null > /var/mail/relay-domains
/usr/bin/wget http://xx.xx.xx.xx/secmail/domains  -O /etc/mail/relay-domains
/etc/init.d/sendmail reload

xx.xx.xx.xx = the IP address or hostname of your primary (Direct Admin) server.

2. Now, the only thing left to do is to type this as root:
Code:
touch /var/spool/cron/root && echo "*/5 * * * * /etc/mail/updatedomains.sh >/dev/null 2>&1" >> /var/spool/cron/root && service crond restart

This will cause the domain list to be refreshed every 5 minutes.

- For this to work, you will have to designate the secondary server as the MX host for every domain that it will be relaying.
- You can have more than one slave server

You can, of course, find a way to enable only the secondary server to read the "domains" file on the master as a security measure, but I leave that up to you.

I hope this will help someone.

Dejan

P.S. I'm not too good in scripting so I apologize if this looks clumsy to anyone :)
 
Last edited:
If you don't check against legitimate usernames on this secondary server, then what happens if the mail is eventually refused by the primary MX? I ask because according to RFCs once you've accepted it you must either deliver it or return it, and on today's Internet, if you return it, since most spam is sent from forged senders, you're going to be on a lot of spam blocklists yourself in a short period of time. So you can't deliver it and you can't return it. What do you do with it?

I highly recommend that anyone considering this consider all the ramifications.

Jeff
 
Thanks Jeff.

That's a good point, although I'm not sure what happens with ISP's or hosting providers that are giving the "secondary e-mail server" service.

Is there any way of checking for legitimate usernames from secondary to primary server?

Secondary MTA could always "temporarily reject" (a 450 error code) any email. If the mail is legitimate, the originating server will try again to send it later (within a few minutes), at which time the destination will accept it.
If the mail is from a spammer, it will *probably* not be retried so the spam will not be relayed.
 
Last edited:
You can change:

Code:
touch /var/spool/cron/root && echo "1,6,11,16,21,26,31,36,41,46,51,56 * * * * /etc/mail/updatedomains.sh 1>/dev/null 2>&1" >> /var/spool/cron/root && service crond restart

to

Code:
touch /var/spool/cron/root && echo "*/5 * * * * /etc/mail/updatedomains.sh >/dev/null 2>&1" >> /var/spool/cron/root && service crond restart
 
That's a good point, although I'm not sure what happens with ISP's or hosting providers that are giving the "secondary e-mail server" service.
I'm not sure what they do or how they do it; perhaps they just don't care if their IP# gets blocked. Or perhaps they ignore the rules and drop the emails. We all (using spam filters) ignore the rules and drop emails all the time; the problem is when users are misaddressed because of a slight misspelling; the senders think their mail has been delivered.
Is there any way of checking for legitimate usernames from secondary to primary server?
You can update lists often and check against the lists to decide whether the mail should be accepted for later relay, or refused.
Secondary MTA could always "temporarily reject" (a 450 error code) any email. If the mail is legitimate, the originating server will try again to send it later (within a few minutes), at which time the destination will accept it.
If the mail is from a spammer, it will *probably* not be retried so the spam will not be relayed.
Not usually. Most MTAs won't look up the recipient MX address again; they'll keep trying the secondary MX server.

You could of course, on the secondary, first try to see if you can deliver the mail, and if so, accept it; if not do a temporarily reject. That should work. However I don't see how different that is than just letting the email not get accepted at all (no working mx), since both are subject to the same rules as to how long to retry before giving up.

Jeff
 
I wouldn't say that ISPs don't care about their E-mails being blocked. Quite the contrary.

On the other note - the "greylisting" happens this way:

-- Source MTA sends the E-mail to destination MTA
-- Destination MTA checks if Source is in its database of known sources. If yes, it will accept the mail. If not it will reject it with 450 Code (mailbox busy) or something like that.

-- Spammers will most probably not retry the delivery (or they will be trying from another IP address)

-- Regular Source MTA will, however, after some time, try the delivery of message that is not delivered based on its setup, but this time, the database of the Destination MTA will contain the IP address of Source and the E-mail will be accepted.

Of course, the greylisting should not be the only way of filtering the spam.


Please understand that I'm not forcing anyone to use this particular method, nor I am expert for E-mail protocols, but surely all of those people using the secondary MX hosts have some point why they do that :D

It works for me, though, and quite well, while I'm at that.

As for the RFCs - at least about SMTP protocol - I think it's a bit outdated and it should use some revisions. Back when it was written, the computer users were generally much more ethical than today if you catch my meaning.
 
But that still doesn't tell us what you do with email that is undeliverable on the main server once it comes back up.

If you delete it, then if someone wrote an important email but misspelled the destination address (haven't we all made that mistake), what happens to it? Do you presume all emails that pass the greylist test are good, and return them, if you can't deliver them?

Jeff
 
Of course, the greylisting should not be the only way of filtering the spam.

As for what I do with the E-mails answer is quite simple: Whatever customers decide to do with them. DirectAdmin gives plenty of options.
Some choose to delete the spam, some to mark and deliver (or return)...

So far I haven't had any problems with blacklists.

As for mispelled e-mail address - yeah, it happens, but if the subject is really that important, there is always something called "Read receipt" failing which you can simply call the guy and check if he got it. :)
 
Last edited:
I think that you are missing the point.

Let's do an example:

- there are 3 domains, one.local, two.local and three.local
- every domain has 2 valid recipients, admin and user

With your setup the secondary server knows only the domains, not the recipients.

Let's imagine a normal request for a delivery to [email protected]l:

- if the primary MX is up, email gets directly rejected -- error coming to the sending user by his MTA
- if the secondary MX receives the email, it will accept it; then, when it can connect to the primary MX, the email gets rejected and an error message will get to the sending user from the secondary MX MTA

All seems to work fine, but now imagine a spoofed request, usually created by SPAM MTAs, to [email protected]l:

- if the primary MX is up, email gets directly rejected -- SPAM MTA gets an error and probably erases the address from his lists
- if the secondary MX receives the email, it will accept it; the email is confirmed as working by the SPAM MTA; then, when it can connect to the primary MX, the email gets rejected and an error message will get to a random recipient out there, from the secondary MX MTA...

There are two major problems. The first will make that address never go away from the spammers lists and therefore hammering your servers... the second will probably blacklist your secondary MX address really fast.

My company had those two precise problems and I have been charged to solve it.
I can't post any code as it's a secury operation center, and anyway I wasn't using DA... but the raw solution is to parse /etc/virtual/domains, /etc/virtual/passwd and /etc/virtual/aliases to create a complete list of recipients, then limit the recipients on the secondary MX based on this list.
This way the secondary MX will always give the exact same answer as the primary one. You can also try to emulate the mailbox-is-full and other common errors, but this was beyond our needs.

Just be sure that the list is always updated and synchronized between the servers.

P.S.:
Greylisting is a great antispam method, it should be an option in DA (maybe through custombuild). I use greylistd and it's working perfectly.
 
uhm... is there anzthing that prevents me to "reject" the e-mail from the secondary e-mail server by default for the first time, no matter the destination mailbox ?

Wouldn't that solve the problem ?

I didn't have any problem so far with this approach.


P.S. I will write this for the last time:
Whatever I have written in this post was written in order to help someone.
If you find it useful - use it.
If not - I'm not forcing anyone, not even to try it out.
 
Last edited:
[...]
Wouldn't that solve the problem ?
Greylisting of course reduces spam by ~95% (from my statistics), but it doesn't solve the problem. It's just a workaround which minimize the problem, but the problem is still there for the spam that passes.
[...]
All the best guys - this is the last one on this from me.
No need to be offended :) sorry if you did.
I'm just trying to help, like you did, and add my experience to your guide... answering to Jeff's doubts in the meantime.
 
Greylisting of course reduces spam by ~95% (from my statistics)

I would say that 95% is pretty good result. About the same here, without any legitimate mails lost.


No need to be offended :) sorry if you did.

Not at all. Just stated the opinion. Since the method I have written out works for me - I thought it would be helpful. No need for me to write more on this topic.
This, of course, doesn't mean it should or would work for anyone else.

English is not my native tongue, so it is possible that I haven't put my words properly...
 
Last edited:
Greylisting is a great antispam method, it should be an option in DA (maybe through custombuild). I use greylistd and it's working perfectly.
I could never make greylistd work with DirectAdmin so I implemented nolisting instead.
Your link may have some information to help, though:
This package contains a script to configure support for greylisting in Exim 4.
Can you post a copy of the script?

Thanks.

Jeff
 
I had to hack the original script a bit to make it work with DA, here is my config based on SpamBlocker 3.1-beta (a modified it a lot, but it should work nice with the original one too... or with any other config):
Code:
[...]

# GREYLIST
  defer message = $sender_host_address is not yet authorized to deliver \
                  mail from <$sender_address> to <$local_part@$domain>. \
                  Please try later.
  log_message = greylisted.
  !hosts = +relay_hosts : \
  ${if exists {/etc/greylistd/whitelist-hosts}\
  {/etc/greylistd/whitelist-hosts}{}} : \
  ${if exists {/var/lib/greylistd/whitelist-hosts}\
  {/var/lib/greylistd/whitelist-hosts}{}}
  domains = +relay_domains
  !senders = : postmaster@*
  set acl_m6 = $sender_host_address $sender_address $local_part@$domain
  set acl_m6 = ${readsocket{/var/run/greylistd/socket}{$acl_m6}{5s}{}{false}}   
  condition = ${if eq {$acl_m6}{grey}{true}{false}}

###############################
# ACCEPTING EMAIL BEGINS HERE #
###############################
[...]

This works only with this particular greylistd (found on debian repositories), which has a nice socket interface.

Of course you can use any other exim-compatible greylisting program just modifying the way it manages the whitelists and the acl/condition.

We are a bit OT here, sorry.
 
Last edited:
Did you have to recompile or do anything special to the DirectAdmin exim package? Or did you use some other exim package?

Do you know how to unpackage the files and tar them up as a simple tarball? If you can do that I can probably get someone more knowledgeable than I am :) to make an rpm or installable tarball out of them so they can be used on other OS distributions.

Jeff
 
Did you have to recompile or do anything special to the DirectAdmin exim package? Or did you use some other exim package?
No and no, I used the original DA exim package installed normally.
Do you know how to unpackage the files and tar them up as a simple tarball? If you can do that I can probably get someone more knowledgeable than I am :) to make an rpm or installable tarball out of them so they can be used on other OS distributions.

.deb packages are 'ar' archives with a very custom config, and that .tar.gz is based on that config... you will have to implement autoconf or a python-related installer.
Other distributions (Fedora, OpenSUSE) seem to have an .rpm of it, but it's custom too and I can't find any usable .src.rpm.

I'm gonna try to build a generic autoconf (or any other wide spread installing framework) .tar.gz, I'll let you know.
EDIT: it may take a while... I'm a CMake lover, but I won't use it as I'm trying to make it compatible with any fresh-installed *nix system. Does anyone knows any wide-spread alternative to autoconf which would be less... painful, for a python script?
EDIT2: I just found about setup.py and 'from distutils.core import setup', I'm close. ;)
 
Last edited:
I'm not sure if this is going to rain on your parade or not but I read somewhere recently that the next version of Python is going to be completely different; almost a different language.

I can't find it now; maybe I'm dreaming. Hopefully ;).

Good luck. Keep us posted.

Jeff
 
greylisting with postgrey +exim +Debian

I'm not sure if this is going to rain on your parade or not but I read somewhere recently that the next version of Python is going to be completely different; almost a different language.

I can't find it now; maybe I'm dreaming. Hopefully ;).

Good luck. Keep us posted.

Jeff

Just a FYI...we are running Debian Etch with postgrey 1.31-2.1 using an exim.conf file with this at the top (modified) DirectAdmin exim.conf #
# SpamBlocker with VirusBlocker #
# Dovecot Enabled #
# Version 3.0-beta

We have been running it for over a year since we started to use DA and it works very well.
Postgrey is a standard package in Debian and gets security upgrades as needed.

I am not sure how this would work with Centos as I have not played much with Redhat .

If someone is running Debian and they feel this would help them I can post what I added to exim.conf and to the standard postgrey config.

WBA
 
Back
Top