The K Blag

With the Sun Java Messaging Server, you can block inbound mail based on the senders E-Mail domain (as self-reported in their E-Mail), also known as their From: address. In the example here, I want to block all inbound email with a From: address from Zambia (TLD: .za). It doesn’t matter where in the world it is sent from, any inbound E-Mail that is said to be from a .za domain will get blocked automatically.

In order to keep my mappings file (/opt/msg/msg-test/config/mappings) more readable, and to keep the items organized, I created a file of domains that I block, and include it in my mappings file in the right section. I named my file /opt/msg/msg-test/config/orig_send_access_block.txt .

I do an include of the file in the ORIG_SEND_ACCESS section of the mappings file. It is the first content line, as such:

ORIG_SEND_ACCESS

</opt/msg/msg-test/config/orig_send_access_block.txt
tcp_local|*|tcp_local|* $N$D30|Relaying$ not$ allowed

The contents of the orig_send_access_block.txt file are as follows (each line is indented 2 spaces):

tcp_local|*.za|*|* $NNo$ thank$ you$ Zambia

I ensured the files were readable by the id that runs Sun Java Messaging Server, then re-compiled and restarted the imsimta dispatcher.

./imsimta cnbuild

./imsimta chbuild

./imsimta restart

bookmark to

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

Like many others, I’ve been receiving an ever greater amount of Spam in my E-Mail box. I decided to take action and deploy SpamAssassin on my Sun Messaging Server (6.3) in order to reduce amount of Spam E-Mail I receive.

First of all, I deployed SpamAssassin. Being as I’m on Solaris 10 x86, and use Blastwave for package management; I installed SpamAssassin thusly:

pkg-get -i spamassassin

It will install all the pre-requisite packages; as well as the SpamAssassin package. With SpamAssassin, there is a tad bit of post-installation configuration (to set it up to run as a service) located at /opt/csw/doc/spamassassin/README.CSW.

When SpamAssassin’s spamd process is successfully up and running the Sun Messaging Server configuration needs to be modified in order to call out to SpamAssassin. This is done first by creating a configuration file, generally in the config directory. I named mine spamassassin.cf with the following contents:

host=127.0.0.1
port=783
debug=1
mode=1
field=

host denotes where the spamd daemon lives; in my case on the local host.

port denotes what port the spamd daemon is listening to; in my case 783 (default).

debug denotes whether the Sun Messaging Server maintains debug information about its talking to SpamAssassin; 0 for off, 1 for on

mode denotes when a score will be handled. mode=0 specifies that no result string is returned. mode=1 specifies that the SpamAssassin result string is returned if the message is found to be spam. mode=2 for all messages

field specifies a string prefix for the SpamAssassin result string.

The config I have above works well for filtering messages based on score into a separate folder. A later post will make some changes in order to reduce messages that exceed a higher score.

Another change needs to happen to the option.dat file (located in config). Add the following lines to this file.

!
! SpamAssassin
spamfilter1_config_file=/opt/msg/msg-test/config/spamassassin.cf
spamfilter1_library=/opt/msg/msg-test/lib/libspamass.so
spamfilter1_optional=0
spamfilter1_string_action=data:,require “fileinto”; fileinto “Spam”;

The spamfilter1_config_file is the location of the config file above.

The spamfilter1_library is the full path to the .so file for libspamass.so that comes with Sun Messaging Server.

The spamfilter1_optional denotes whether SpamAssassin is bottlenecking inbound mail (0) or it will proceed and deliver as normal if SpamAssassin has an error (or is not up) (1).

The spamfilter1_string_action specifies what happens when a message is found to be Spam. In our case, it will file it into a folder named Spam.

The final step is to update the imta.cnf file to specify that messages should go to the Spam Filter. Update the ims-ms line to add the destinationspamfilter1optin spam option to the line.

After deploying SpamAssassin, mine looks like:

ims-ms defragment subdirs 20 notices 1 7 14 21 28 backoff “pt5m” “pt10m” “pt30m” “pt1h” “pt2h” “pt4h” maxjobs 2 pool IMS_POOL fileinto $U+$S@$D destinationspamfilter1optin spam

With a final ./imsimta cnbuild; ./imsimta chbuild; and an ./imsimta restart; Spam filtering should be in place.

Reference information from Sun about deploying SpamAssassin.

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