Piratefish Implementation
There are many numerous ways to deploy the Piratefish system, each with it's advantages and disadvantages.
For the vast majority of you, one of the listed configurations is similar to how your email server is setup now.
or
Please read the section that is more appropriate to your configuration, below.
Section 1: Mail Server with Public IP address.
In a configuration like this, it's best to give the Piratefish a public ip address as well. If you do this, then the only other thing you will need to do is assign it an IP, protect it, and change the DNS.
Removing a mail server from having a public IP isn't a good idea as this can interfere with sending messages, and it makes reaching web mail interfaces much more difficult as well.
One downfall from this configuration is that even though DNS will direct email to the new server, some spammers search for server IP addresses and could still bypass the Piratefish by delivering the messages directly to your server. Remember that spammers don't always follow the rules - delivering email to a properly defined mail server is only a suggestion to them.
Blocking port 25 inbound to your old email server from the Internet could be done, but that would interfere with external email users if you're using smtp/pop3 for external email.
One other option for this type of implementation is to re-direct port 25 traffic aimed at your Mail server so that it delivers directly to your Piratefish for scanning. Once again, doing this could interfere with external users who need to send email over port 25, but one method of avoiding this is to use some clever port translation to re-direct internal SMTP users away from port 25.
One disadvantage of this configuration is that the Internet needs to be told that the Piratefish is now scanning your email - and this means that you've got to direct inbound email to it by changing the DNS entries for your mail server.
A small section about modifying DNS entries
So lets say, for example, you have a mail server with the public IP address 1.2.3.4 called mail.domain.org and you have your new Piratefish at IP address 1.2.3.5. If your DNS record had only one MX entry (Mail eXchanger), it would appear like this:
domain.org MX preference = 10, mail exchanger = mail.domain.org
The Piratefish in this situation will need it's own DNS entry, lets call it piratefish.domain.org and that entry will point to IP address 1.2.3.5. Now to direct email to this server, you'll need to change your DNS so that the MX record points to the fish. A simple replacement would get you this:
domain.org MX preference = 10, mail exchanger = piratefish.domain.org
If you're really paranoid, then you could make two MX records, like this:
domain.org MX preference = 10, mail exchanger = piratefish.domain.org
domain.org MX preference = 20, mail exchanger = mail.domain.org
This would ensure that no messages are missed - but if the spammers figure this out, they'll just keep delivering to the second server.
Section 2: Mail Server with Private IP address and NAT
In a configuration like this, the Piratefish can be located anywhere behind your firewall. If your email server is located on your company's main network, then this is an excellent opportunity to segment your network and increase your security. By isolating your Piratefish from the rest of your network, you add the assurance that anyone hacking into the fish won't have an open door into your network.
This configuration also offers some flexibility in terms of traffic re-direction, as it would be possible to direct inbound SMTP traffic directly to the fish, while hiding it's web access behind the same IP address as that used by the mail server itself. Using this method with a load balancing firewall could even turn a school of fish into a load-balanced inbound mail processing system.
One clear advantage of this configuration is that no changes are needed on the public DNS record. This also permits you to make quick and easy changes to remove the fish if necessary.
