2009.07.29
RHCE Flash Cards Released
2008.01.11
Website Design Updated. This is a work in progress...
2008.01.11
RHCE Study Guide Removed due to a potential copyright issue
2007.12.03
RHCE Study Guide Released
Status: Commercial (<a href="http://www.rockliffe.com/">Rockliffe</a>) Systems: Win/NT, Win/95, Win/98 Info: <a href="http://www.rockliffe.com/">http://www.rockliffe.com/</a>
Status: Commercial (<a href="http://www.microsoft.com/">Microsoft Corp.</a>) Systems: Win/NT Info: <a href="http://www.microsoft.com/">http://www.microsoft.com/</a>
Versions through 5.0 are vulnerable to relay if they permit any local SMTP users. (Servers that only act as a gateway between internal non-SMTP mail and the Internet don’t have relay problems.) In other words, if your Exchange 5.0 server is connected to the Internet, it WILL relay for anyone, and that cannot be stopped.
Starting with version 5.5, provisions have been made to prevent unauthorized relay. These are described in detail in an article from Windows NT Magazine. If you’re running an older version, it’s time to upgrade.
<!Status: Freely Available Systems: Unix Info: <a href="http://www.sendmail.org">http://www.sendmail.org/</a>
Versions before 8.8.4 require serious configuration hacking, and even then they aren’t totally secure. Time to upgrade.
Rulesets for version 8.8.x are available from Claus Aßmann’s web site at sendmail.org. There are others around, but Claus’s tend to be updated the most frequently.
Many sites which run 8.8.x have added anti-relay configuration, but are still susceptible to the “percent hack.” Please pay special attention to the removelocal portion of check_rcpt in Claus’s recipes to fix that.
Another approach is to <a href=”http://spam.abuse.net/tools/smPbS.html”>limit mail server access to only those users who have authenticated themselves with a POP password. This is the so-called POP-before-SMTP solution. Although this is more complicated to setup, it is an excellent solution for providers that have “roaming users.”
ISPs that are members of the iPass network should email <ask@ipass.com> to obtain the “Anti-Spam Kit” for sendmail 8.8.
Starting with version 8.9.0, sendmail prohibits relay by default, and provides a number of parameters to control this feature. See the Anti-Spam Configuration Control section of the cf/README file for information on these settings.
Caution: Most of these solutions require you to setup a list of domains to which relay is allowed. Be sure to include all authorized domains in this list. Don’t forget downstream domains for which you MX, as well as virtual domains that you serve. Otherwise you will begin rejecting mail that you shouldn’t.
Another caution: if you have confiured sendmail 8.9.3 with FEATURE(relay_entire_domain), this will accept relays from any host in your domain. What’s “your domain”? It’s your host name with the first “word.” stripped from it. Unfortunately, by default, sendmail checks EVERY IP address on your system and does reverse lookups.
Many systems have a default as-shipped ‘localhost.rev’ that has 127.0.0.1 point to localhost.berkeley.edu or something like this. This means that any host in berkeley.edu will be able to relay, but your own hosts may be rejected. There other services that rely on your server having correct reverse DNS as well, so it’d be a good idea to fix this.
Many, many, systems have at least one virtual host where the reverse DNS just points to the domain name, e.g., xxxstuds.com or some similar thing. This is where you end up with an open relay; such a machine will relay for anything in ’.com’. Similarly, if you had a virtual host (or even just your main IP) resolving to ‘example.net’, you would discover that anything in ’.net’ was allowed to relay.
The best solution is to upgrade (including the .cf file); if for some reason you can’t do that, specify relay hosts by IP address instead of using relay_entire_domain.
<!Status: Commercial (<a href="http://www.sendmail.com/">Sendmail</a>) Systems: Unix, Win/NT Info: <a href="http://www.sendmail.com/">http://www.sendmail.com/</a>
This commercial version of sendmail should have the same relay control features as the free, open source sendmail 8.x, plus a graphical interface intended to make configuration easier and all sorts of technical support options.
<!Status: Commercial (<a href="http://www.novell.com/">Novell</a>) Systems: Unix Info: <a href="http://www.novell.com/groupwise/">http://www.novell.com/groupwise/</a>
GroupWise 5 GroupWise Internet Agent (GWIA) may be partially secured against unauthorized relay. This is not, however, complete relay control, and spammers may still take advantage of your system.
Using NWAdmin, go to the details page of the Gateway. Click on the “Access Control” tab, and then the “SMTP Relay” button. Check the “Prevent Message Relaying” radio button, then click OK.
There is a workaround to secure the GroupWise SMTP/MIME gateway. Edit the DOMAIN/WPGATE/SMTP/GWSMTP.CFG file (with any text editor) and add the switch ”/NOROUTING”. Mail relay will now be disabled. If you have the option set to save problem mail, the messages instead will be saved into your problem directory, so be sure to keep an eye on it.
In version 5.5, add ”/NOROUTING” to the GWIA.CFG file in the SYS:SYSTEM folder.
We’ve been told that these relay control features simply do not work before version 5.5.4, and that even after 5.5.4 quoting the recipient address will bypass all of Groupwise’s relay controls. Spammers know this, too.
NEW: it seems Novell has released a patch which is reported to fix the “quote hack” in 5.5.4 (aka Groupwise 5.5 with Service Pack 4.) This patch will not work on earlier versions of Groupwise, or if SP4 is not installed. We had a copy of the documentation from the patch here: dnload/fgwia55b.txt, and the self-extracting archvie itself at dnload/fgwia55b.exe, but no longer see a need to provide the files. It is unclear why Novell did not have this patch on their own web site, and even more unclear why they did not mention relaying at all in the documentation.