A private BSD laboratory

Did you read my previous posts about RcptFilter? After having put in production the third BSD server running BIND and Sendmail with ClamAV, I decided to extend a bit the central management configuration features of that tiny scripting solution. At scheduled times, few Perl and MSFT shell scripts running on a Windows Server 2003 machine produce and publish on a public web location a compressed archive containing all configuration files we need to distribute on all our BSD managed servers.

Some troubles occurred in generating the configuration files, because the Microsoft text file format is a bit different (each line ends with CR and LF characters instead of using LF only, as all Unix-like machines do), but with the utility dos2unix all came back compliant.

Considering the settings we need to centrally manage for our few servers, this solution fits well until now, but I wish extend it in order to distribute even some machine-specific settings, maybe using authenticated and protected channel to the hosts and a central repository of policies. Looking also forward to find a good solution which, I am sure, it has already been developed by good Unix administrators out there.

I had setup a front-end SMTP relay system one more time, running on the latest release currently in the stable branch of the FreeBSD Project development (6.2).
I’m a bit experienced in running Sendmail on BSD systems, so I spent only few minutes to configure and test e-mail routing, and I took some time for having a look at a strange behavior that I’m not be able to understand yet.

Think as if the host name was mx2.mydomain.com: since I had to build it as a secondary mail exchanger for several email domains, after the insertion of all the domains in the relay-domains Sendmail configuration file, I wrote in the mailertable to have all messages sent to these domains relayed to the primary SMTP inbound server (maybe located in a different location), by inserting this lines:

With this config, delivery problems came for the messages sent to the first domain, whereas all mail sent to others domains were successfully relayed. The error messages that appeared in the log files were suggesting a clear matter: “stat=Deferred: Name server: mx1.mydomain.com : host name lookup failure”. This should not leave you any doubt, but after I checked there was not any name resolution problem, I found that a bit strange: in fact, why only delivering to the first domain was faulting?
I decided to change the mx1.mydomain.com name with its corresponding IP address, and all worked fine, for all domains!

After a lot of testing, I found that Sendmail seems not to be able to relay any message to the primary MX if its FQDN lies in the same DNS domain of the Sendmail host!! I posted this unbelievable matter in the comp.mail.sendmail newsgroup, but I haven’t got any reply yet… please someone show me that the problem is due only to an error in my configuration: I cannot believe there is such a serious bug in Sendmail without anyone has ever noticed it! :S

Yesterday night I spent more than five hours on a FreeBSD 6.1 system in testing the clamav-milter service. Do you remember my last post, in which I wrote about the need to migrate all my SMTP front-end systems to the FreeBSD platform in order to achieve a better security check on incoming e-mail traffic? Now I’m able to run a Sendmail daemon tailored to my corporate needs which works together with a good (and free) virus scanning engine, dropping infected e-mails at the SMTP connection stage without generating any NDR (Non-Delivery Report) to the sender address. Also the reporting feature (an e-mail to the postmaster mailbox) in case of virus detection fits well in my environment, where there is no scheduled notification sent to the postmaster address.

I had to work a lot to find the best installation method for my production environment: after I built all the packages needed by ClamAV (by inserting the right flags during the make process) I was able to setup the latest version of the product on the production systems without installing the ports collection. Now I want to observe it running for some days before migrating the primary SMTP front-end system too.

I must admit that I’m going to be convinced to rebuild all my front-end SMTP servers with FreeBSD systems running Sendmail, because of some important features still missing even in the ‘SMTP Transport’ role of the new Exchange Server 2007… 🙁  I already have such a system running in my corporate production environment, running as my secondary mail exchanger system, but before completing the migration to the BSD platform I would like to accomplish some additional steps.

One of the most relevant requirements is the ability to check the RCPT TO data and verify that the recipient is actually existing and active in every back-end Exchange organization, so I have spent some time to rebuild the RcptFilter solution, as I explained in the post before. Since then, I realized that to have the access file rebuild process running on each mail server is not just the best way to sync the GAL with Sendmail, since I should allow each mail server (both internal and Internet systems) to access all the Domain Controllers via LDAP, in order to let them obtain the global address list from the Exchange organization which rely on Active Directory Services to store its data.

Thus I decided to centralize the access file rebuild process, by scheduling the perl scripts execution onto the Windows Server 2003 R2 system built to be used by our IT Services group for their administrative, monitoring and management tasks. After the access file is rebuilt (everyday at the 12:00 AM), it is compressed and published on a web server to be accessible to all my FreeBSD systems, which simply have to fetch and unpack it, then to rebuild the access.db file and restart the Sendmail daemon.

So my centralized RcptFilter system is ready to run, now I only wish to bind a virus scanning engine to Sendamil before making it my first and unique SMTP Internet relay system!

The backup SMTP server for my public domains are running on a FreeBSD platform (it is a Sendmail daemon). Since its unique function is to relay messages to authoritative Exchange servers, it has no connection with the directory service maintaining information about active mailboxes, therefore it cannot understand if a recipient address of a message is to be managed as a valid address, even if it is sent to one of my public e-mail domains.
Obviously this behavior has always been causing the generation of many NDRs (Non-Delivery Receipts), because of the large amount of messages sent by spammers to invalid SMTP addresses. Furthermore, several NDRs cannot be delivered because also the sender SMTP address is often crafted, so generating a painful message flow and queue growth.

Since I have no time to spend in administering my Unix servers, after I tried to make Sendmail able to lookup the Active Directory at each “rcpt to” submission I took off, because it was a solution too expensive to fit my needs until some days ago, when I found a great message posted by someone who was experiencing the same concerns about the NDR message flow.

The solution is essentially build onto some perl scripts which compose the active recipient list by querying the Active Directory. Then they compile the “access” file needed by sendmail to build the relay control database “access.db”, by reading also the information contained in the “relay-domains” file under the /etc/mail directory.
I had only to write a shell script to unify all the operations (query the LDAP server, build the access and the access.db files, reload Sendmail daemon) and my Sendmail is fnally able to know if the “Rcpt to” field is a fake or valid SMTP address, without any complex MTA code change!