The K Blag

Recently, I needed to enable E-Mail reminders for Sun Java Calendar Server 6.3.  I thought they were enabled by default, and peering through the documentation available, thought I had confirmed my suspicions.  However, being pragmatic with the available documentation, I decided to specifically define the available configuration options.

In the /opt/SUNWics5/config/ics.conf file, I changed the following option from:

!
! Enable binary alarms.   Used by csnotifyd and csadmind.  (default:  yes)
!caldb.serveralarms.binary.enable = “yes”

To the following:

!
! Enable binary alarms.   Used by csnotifyd and csadmind.  (default:  yes)
caldb.serveralarms.binary.enable = “yes”

And restarting the server.  Voila!  Uncommenting the (supposedly) default value worked!  Calendar E-Mail reminders enabled.

bookmark to

I’ve been getting increasing amounts of Unsolicited Bulk E-Mail, or Spam from certain ranges of IP Addresses that have not been sending any legitimate E-Mail. I’ve wanted to block these IP ranges when they first connect to the mail server, and before my (expensive) Spam filter needs to run.

The first step is to identify the IP addresses sending you bulk E-Mail; or if you want, you can get an entire set of IP Addresses, already sub-netted for use by Sun Messaging Server at http://ip.ludost.net/. For our purposes here, we want to block the IP Address range 192.231.176.0/24.

Create a file (much easier to maintain a single file than to continually edit the mappings file); with a name like port_access_block.txt and add the line as such (note, there are 2 spaces at the beginning of the line):

TCP|*|25|$(192.231.176.0/24)|* $T$N500$ No$ thank$ you

when the file is created, edit the mappings file, adding a link to your newly created file in the PORT_ACCESS section. My updated PORT_ACCESS section looked like:

PORT_ACCESS

</opt/msg/msg-test/config/port_access_block.txt
*|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E
* $YEXTERNAL

Ensure the port_access_block.txt is readable by the user running your mail server; then recompile and restart your messaging server.

All E-mail to your mail server from remote machines in the IP address range listed will rejected immediately with a fatal error.

bookmark to

One of the best weapons I’ve used in the larger battle against unsolicited bulk Email, or SPAM, as it is commonly referred; is Greylisting.
Greylisting is very effective for reducing the volume of SPAM an Email server takes in by returning a temporary error during the conversation to the remote MTA, essentially saying to come back in a few minutes. While some MTA’s do not support resending, the vast majority do.
grossd takes this a bit further. While also working with the Sun Messaging Server (6.3 in my case); it only forces the temporary error for remote MTA’s that are on its set of blacklists. While it doesn’t explicitly reject the message outright, it does force the remote MTA to at least retry in order to send the message.

Configuring a (standalone) Sun Messaging Server MTA is fairly straightforward. It requires the c-ares DNS library to be compiled and installed. Then the grossd code needs to be compiled and installed. A gcc compiler other than the default installed in /usr/sfw on Solaris 10 may not be sufficient.

The summary installation instructions for c-ares.

# gunzip -c c-ares-1.4.0.tar | tar xf -
# cd c-ares-1.4.0
# ./configure –prefix=/usr/local
# make && make install

The summary installation instructions for grossd.

# gunzip -c gross-0.8.2.tar.gz | tar xf -
# cd gross-0.8.2
# ./configure –prefix=/usr/local
# make && make install

I needed to make a single change in /usr/local/etc/grossd.conf; which was to simply comment out the following line:

protocol = postfix

So that it reads:

#protocol = postfix

Once grossd is configured, it needs to be started, and probably have a startup script to automatically make it run at boot.

#!/sbin/sh

case “$1″ in
start)
[ -f /usr/local/etc/grossd.conf ] || exit 0
/usr/local/sbin/grossd -f /usr/local/etc/grossd.conf
;;
stop)
pkill grossd
;;
*)
echo “Usage: $0 { start | stop }”
exit 1
;;
esac
exit 0

I started grossd using the script:

# sh /etc/init.d/grossd start

# ps -ef | grep -i gross

root 21356 1 0 Oct 24 ? 9:00 /usr/local/sbin/grossd -f /usr/local/etc/grossd.conf

With grossd running, the Sun Messaging Server config needs to get tweaked. Edit the mappings file; adding the following section. Please be careful to have a complete newline before the beginning of the section, immediately following the section name, and following the contents of the section. There are 2 spaces leading off the TCP line, in case they are not clear.

ORIG_MAIL_ACCESS

TCP|*|*|*|*|*|*|tcp_local|*|*|* $[/usr/local/lib/grosscheck.so,grosscheck,127.0.0.1,,1111,$2,$=$8$_,$=$6$_]

After making this change, recompile the configuration, and test grossd.

# ./imsimta cnbuild

# ./imsimta chbuild

After testing; restart the messaging server;

# ./imsimta restart

To determine the number of messages that greylisting has worked on, you can grep on the mail logs for the string “452 4.4.3″

# grep -ic “452 4.4.3″ mail.log_current

29536

bookmark to

One of the largest problems that I have noticed when doing directory deployments, are either invalid, or non-existent backups of their directory information.  They often assure peace of mind when things unexpectedly go wrong (a la unexpected power outages).

I’ve found a good reference to how to do backups with Directory Server 6; and won’t rehash them here.

In essence, it may become necessary to have a single instance dedicated to doing routine backups in a large environment.  This is because you need to be able to turn the instance to read-only for the duration of the backup.

bookmark to

I’ve installed many, many Sun/Netscape/Fedora Directory Server instances. There has been plenty to like, and much to dislike as well. I’m big on not using the console for most things, as by nature, I’m a command line type person. The most compelling reasons for me to move to Directory Server 6:

Much improved command line functionality

It is now possible to install the directory server bits, create a new directory server instance, and perform configuration commands on the directory server using command line tools. While you could do some of the features before using things like an installation script, or using LDIF, these commands are called directly from the command line without superb internal knowledge of how to implement these functions.

As an example, creating a new directory server instance with pre-DS6 used to require either a trip to the console (if you were lucky enough to have enough access to the machine); or the use of an silent installation script.

By contrast, you are able to create a new instance with DS6 with a simple command (albeit, it does ask for the directory manager password) (these commands assume it was installed in /opt/ldap):

cd /opt/ldap/ds6/bin

./dsadm create -p 389 -P 636 /opt/ldap/slapd-test

And create a new suffix with another simple command (you’ll need the directory manager password):

cd /opt/ldap/ds6/bin

./dsconf create-suffix -h localhost ‘dc=domain,dc=com’

There are plenty of other examples that can be had, such as creating and initializing replication agreements, but those can be left for another day.

Unlimited number of masters in Multi-Master Replication

With the release of DS6, the number of masers in an MMR increased from a maximum of 4 to unlimited. This can result in each instance in your environment being promoted to a master instance. Practically, this may not suit all environments, as WAN traffic and such comes into play with how your replication agreements are configured.

I’ll probably revisit this topic again in the future.

bookmark to