[no subject]

X-Envelope-Sender: == MAIL FROM:

X-Envelope-Recipient: == RCPT TO:

If this host was secured prior to the test date above, then its antirelay
configuration is either not activated, or is defective. Check the
X-Envelope- headers above in conjunction with the list of envelope
vulnerability tests to determine the failure mode. If it has been secured
since the test was carried out, file it as closed.

Information on securing the server


Sendmail admins: http://www.sendmail.org/tips/relaying.html has quite a few
useful bits of information...

Feature(nouucp) is buggy in all versions of sendmail up into the 8.10 betas.
If you enable this feature, you will need to manually add the ! character
back into sendmail.cf's CO macro.
# operators that cannot be in local usernames (i.e., network indicators)
CO @ % !

Failure to do this may result in your machine relaying for UUCP pathed
checks.

If you need sendmail on a machine so that processes can send out mail, but
no inbound mail facilities are needed, all you need to do is change
sendmail's startup settings by removing the "-bd" flag. It's the -bd flag
(-bD if run in the foreground) which tells sendmail to listen on port 25 and
if that is deleted, it will only deliver locally generated mail rather than
acting as a full-blown mailserver. Please note: this will only secure a
server for as long as the -bd flag is disabled, so should be regarded as a
temporary measure. Eventually, someone is bound to accidentally re-enable
the -bd flag. Wherever possible, please update to sendmail 8.9.3 or later.

Sendmail 4.x, 5.x, 8.6, 8.7: These cannot be secured against unauthorised
third party relaying without major work. Additionally, most versions have
major vulnerabilities allowing remote attackers to execute arbitrary
commands as the sendmail userID (usually root) and which may allow remote or
local attackers to gain a root shell on the server. If you have one of these
sendmail versions, disable or update it immediately and audit the security
of the entire machine, taking particular care to check for installed
backdoors..
Sendmail Inc describe version 8.6 and earlier as "Not supported, not secure
and should NOT be run on a network-connected computer.".
Sendmail 8.7 is full of buffer overruns and multiple cookbook root shell
exploits are widely circulated. If you are running this software disable it!
Sendmail now state in their FAQ that all versions prior to 8.9.3 are no
longer supported
Sendmail 8.8: Some of the antirelay .cf file hacks linked from
maps.vix.com/ar-fix.html don't adequately protect against relay attacks
using %, : or ! pathing control characters in the RCPT TO: header.
Additionally all versions of sendmail prior to 8.8.9 are susceptable to a
HELO buffer overflow attack. 8.8.4 and earlier suffer from vulnerabilities
which allow attackers to gain root shells.
During July-August 1999, several thousand sendmail 8.8 installations were
exploited by a spammer using RCPT TO:<"victim@target"> - with the "" in the
envelope. If you have an ORBS notice with "X-Envelope-Recipient:
<"someone@xxxxxxxxxxx"> " in the last few lines, then this is the test your
sendmail installation failed.
Claus Assmann's check_rcpt Sendmail 8.8 antirelay hacks were updated to fix
the "", %, ! and : vulnerabilties on 24 August 1998 and his work can be
viewed at http://www.sendmail.org/~ca/email/check.html.
These fixes are also applicable to MetaInfo Sendmail 8.8, which is a third
party Microsoft NT port of Unix Sendmail. MetaInfo do not produce a port of
Sendmail 8.9 or 8.10 and because of this, we strongly discourage use of
MetaInfo software - see the comment below about Sendmail 8.8 support. If you
wish to run Sendmail under Microsoft NT, Sendmail now produce this directly
and like MetaInfo's previous ports, this is full commercial software - not
freeware. See www.sendmail.com.
Vintra Mailserver Professional 2.02 appears to be another sendmail 8.8
port - with the same "" bug.
Fujitsu Teamware: Older versions normally use the MetaInfo Sendmail 8.8
package, but Sendmail 8.9.3 has been shipped since 22 February 2000.
More useful information is available at
http://hexadecimal.uoregon.edu/antirelay/
Sendmail 8.8 is unsupported by Sendmail Inc. and there are probably more
relaying and security holes lurking in it. Update to 8.9.3 or later!
Anyone continuing to use a Sendmail version earlier than 8.9.3 is sitting on
a security-related time bomb. Update before your server is abused as a spam
relay or used as a relay point for other attacks.
Sendmail 8.9.0 and 8.9.1 are susceptable to relaying attacks using the :
pathing control character in the RCPT TO:<> header. They are also
unsupported by Sendmail, Inc. Update to 8.9.3. Details of sendmail 8.9 built
in relay/spam protection features can be found at
http://www.Sendmail.ORG/antispam.html

Sendmail 8.10: Sendmail 8.10.2 is out and proven stable
8.10.2 is a bugfix release of 8.10.1 which addresses some dangerous Linux
behaviour.
8.10.1 was a bugfix release which addresses some dangerous AIX linker
behaviour. It has selection of multiple DNS blacklists built in, excellent
SMTP level spam filtering facilities and the ability to switch off spam
filtering/backlisting on a per-user basis for those users who insist on
getting every last piece of spam they want.
Sendmail 8.11: Sendmail 8.11.1 is out and proven very stable. This contains
support for strong encryption thanks to recent relaxation of US Govt export
restrictions and replaced a planned release of 8.10.3.
Update to the latest stable version of Sendmail if you can, these versions
contain the features need to support secure authenticated support for
roaming remote users and will incorporate security fixes as the come along.
Always check Sendmail's website to see what the latest current version is
and view the changelogs.
When upgrading sendmail to secure versions: Always generate a new
sendmail.cf - continuing to use the sendmail.cf from a previous version
which had a relaying vulnerability will usually result in that relaying
vulnerability not being fixed.

A warning from www.Sendmail.org: FEATURE(`relay_local_from') will allow
relaying if the sender specifies a return path (i.e. MAIL FROM:
<user@domain>) domain which is a local domain. This a dangerous feature as
it will allow spammers to spam using your mail server by simply specifying a
return address of user@xxxxxxxxxxxxxxxx - this feature should only be used
on non-Internet connected servers.

If you are uncomfortable with M4 scripting, WIDE in Japan have a .cf
generator which may be useful. It can be downloaded from
ftp://ftp.jpcert.or.jp/pub/security/tools/CF/

Redhat linux users: ftp://admin.netus.com/sendmail/ has sendmail 8.9.3 rpms
you might like to try out. Last update 27 March 1999: "pop-before-smtp with
a DUL map fallthrough from the poprelay ed map".
Linuxconf users beware! - Linuxconf was found to be generating faulty (old)
check_rcpt tables as recently as 20 July 1999. Make sure your version is
newer than this before using it to generate sendmail.cf files. All versions
of Redhat Linux prior to 6.1 were shipped with the faulty Linuxconf. Update!
Sun Admins: Try
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access for
updates to sendmail 8.9.x. Make sure you install the antirelay.cf. Sun's
standard sendmail.cf is a wide open relay...