Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Web Server/CGI)  > Vendors:   Wright, Matt Web-to-Email CGI Script Still Allows Unauthorized Users to Send Mail Anonymously (e.g., Send Spam)
SecurityTracker Alert ID:  1003357
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jan 25 2002
Impact:   Host/resource access via network
Fix Available:  Yes  Exploit Included:  Yes  
Version(s): 1.9 and prior versions
Description:   It is reported that the FormMail perl script still allows remote users to send anonymous mail via the script.

According to the report, a remote user can specify bogus HTTP_REFERER field contents so that the script approves the submission as from a valid Referer. A remote user can also use 'creative addressing' when specifying the recipient so that the script will approve the recipient but actually deliver the message to a different address.

For a summary of demonstration exploit methods, see the Source Message or view:

Impact:   A remote user can use the CGI script to send anonymous e-mail to arbitrary recipients.
Solution:   No vendor-supplied solution was available at the time of this entry.

However, the authors of the report have prepared a new version of the script, available at:

The authors of the new version make no claims to as to the security or usability of this script. They recommend rewriting a script from scratch as preferable to using their revised script.

Vendor URL: (Links to External Site)
Cause:   Input validation error
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)
Underlying OS Comments:  Perl-based

Message History:   None.

 Source Message Contents

Subject:  Anonymous Mail Forwarding Vulnerabilities in FormMail 1.9

A more easy-on-the-eyes Postscript version of the following advisory
may be viewed at:

An entertaining working demonstration of a 100% client-side Javascript
exploit for older and already well-known FormMail 1.6 version security
flaws may be found at:

Use this at your own risk!  And read the documentation before doing so!

A revised version of FormMail 1.9 (which I am calling 1.9s) which is
believed to be free of any and all of the security flaws described in
the advisory below is now available at:

This version is only being supplied for the benefit of those few sites
that are, due to a total lack of programming talent, absolutely and
totally unable to simply remove FormMail and replace it with their own
locally-implemented replacement script.  WARNING:  This alternative
TESTED.  There is NO WARRANTY, either express or implied.  I have been
totally unable to even get into contact with the original FormMail
author, so you may be sure that he has not even seen this (1.9s)
version of his script.

My apologies for the length of this advisory, but there was a lot of
stuff to talk about.  I hope that this will help future implementors
of ``contact us'' type CGI scripts to avoid a lot of pitfalls.

Anonymous Mail Forwarding Vulnerabilities in FormMail 1.9

Ronald F. Guilmette <> - Infinite Monkeys & Co.
Justin Mason <> - maintainer of SpamAssassin

Sun Jan 23, 2002


This  advisory  describes  various methods and mechanisms for the
remote abuse of the widely-used FormMail script, version 1.9,  to
send  arbitrary  e-mail  messages to arbitrary recipients without
the consent of, and against the wishes and  intentions  of  those
who  have installed the script on their web servers.  Essentially
all of the exploits described herein are also applicable to  ear-
lier (pre-1.9) versions of FormMail.

General  information  on the widely-used free FormMail CGI script
may be found at the following URL:


By manipulating inputs to the FormMail CGI script,  remote  users
may  abuse  the  functionality  provided by FormMail to cause the
local mail server on the same (web) server system to  send  arbi-
trary  e-mail messages to arbitrary e-mail destination addresses.
Such e-mail messages may contain real  or  forged  sender  e-mail
addresses  (in  the  From:  headers)  entirely  of the attacker's
choosing.  In some cases, the envelope sender addresses  of  such
messages may also be set to arbitrary values by the attacker.

When  and  if the vulnerabilities described below do exist (which
is dependent, in some cases, upon script installation  configura-
tion  choices  and web server configuration choices) and when and
if they are in fact exploited by  an  outside  attacker,  message
recipients  will  have only incomplete e-mail tracing information
available in the message e-mail headers.  This incomplete tracing
information  will  lead  back  only as far as the web server that
hosts the FormMail script.  The IP address actually used to  ini-
tiate  the  messages  will  not be available to these recipients.
The originating IP address of the attacker  may  or  may  not  be
available  (in local web server logs) to the administrator of the
exploited web server, depending on local web server logging,  log
file  retention  policies,  and  the  length of time that elapses
between exploitation and the time the local administrator becomes
aware  of  the exploitation.  (Of course, even in cases where web
server logs are available, tracing information contained  therein
may  perhaps  allow  tracing  of the attacker only as far back as
whatever anonymizing HTTP proxy the attacker used.)


We have followed the notification guidelines laid out in:

with respect to this  advisory.   Both  authors  of  the  present
advisory  attempted to contact the FormMail maintainer via the e-
mail address given on the  FormMail  home  page  more  than  five
working  days prior to publication of this advisory.  No response
from the maintainer was forthcoming.  Attempt were also  made  to
contact the maintainer via telephone but were unsuccessful.


The  FormMail  script  has  a  long  and  unenviable history with
regards to security issues.  Originally  intended  as  a  helpful
free CGI script, usable in the construction of simple interactive
`contact us' type  web  forms,  it  was  originally  created  and
distributed  July  9,  1995  and  subsequently  underwent several
revisions culminating in version 1.6 which was  released  May  2,
1997.   The 1.6 version became widely used, and copies of the 1.6
version are still  installed  and  publicly  accessible  in  many
locations at the present time.

Sometime  between  the release of the 1.6 version of FormMail and
March, 2001, various Internet users became  aware  that  spammers
were  exploiting  the  relatively modest and weak security checks
within the 1.6 version to send large  quantities  of  unsolicited
`spam'  e-mail  to  large  numbers  of  recipients  via exploited
FormMail scripts.  In effect, spammers were using  the  exploited
FormMail   scripts   in  ways  that  rendered  them  functionally
equivalent to anonymizing open e-mail relay servers.  Eventually,
someone   filed   a  public  security  advisory  regarding  these
exploitations and the now  evident  security  problems  with  the
FormMail   script.[1]  Later  reports  indicated  a  belief  that
spammers were actively searching the net for exploitable FormMail
scripts.[2]  At  least two different parties have apparently been
motivated (by FormMail's evident security problems) to create and
distribute their own independently-developed versions of FormMail
which allegedly close the security loopholes.[3]

Subsequent to the release of the 1.6 version of the  script,  1.7
and  1.8  versions  were  also  released.   On  his web site, the
FormMail  author  himself  notes   that   these   versions   have
unspecified  (and  perhaps  different;  see  footnotes)  security
vulnerabilities, and that all users should upgrade to version 1.9

Version  1.9  of  FormMail was released by its author on or about
August 3, 2001, according to the comments in  the  script.   This
version  has  been  alleged  to  rectify  the  various previously
identified security issues with  FormMail,  including  its  prior
ability  to be manipulated into behaving like an anonymizing open
mail relay.[4]

Pre-1.9 Exploitation

Exploitation of FormMail versions prior to 1.9 for the forwarding
of  e-mail messages which have been effectively anonymized[5] was
rendered trivial by the script's total  reliance  on  information
transmitted by the web client to the web server (and hence to the
FormMail CGI script) for both authentication of the  request  and
for  specification  of  recipient  e-mail  address(es)  for  each

FormMail's authentication of incoming requests, such  as  it  was
(and  is,  in  version  1.9),  is limited to the following rather
rudimentary check on the HTTP_REFERER environment variable passed
to the script from the local web server.  (The web server, in its
turn, obtains this value from the Referer: HTTP  header  supplied
by the HTTP client.)

    foreach $referer (@referers) {
        if ($ENV{'HTTP_REFERER'} =~ m|https?://([^/]*)$referer|i) {
            $check_referer = 1;
else {
    $check_referer = 1;

Note that further up in the script, the original script installer
is required to have defined the @referers  array  to  a  list  of
strings,  each  of  which  is  supposed to be a domain name or IP
address.  These domain names and/or IP addresses  are,  by  their
inclusion  in  the  installer-supplied  definition  of @referers,
effectively authorized to run web servers that will serve up HTML
pages  containing  HTML  forms  that  may work with this specific
locally-installed copy of FormMail.   So,  for  example,  if  the
local  FormMail  installer had wanted to limit the script's usage
so that it could only be used  in  conjunction  with  HTML  forms
resident   on  the  web  servers  known  as  and then the installer would have  previous  defined
the @referers array as follows:

     @referers = ("", "");

There  exist  several  ways  to  easily bypass and circumvent the
HTTP_REFERER checking code shown above.  The  most  obvious  way,
and  the  way that most attackers will certainly use is simply to
decline to provide any Referer: header at all as part of the HTTP
request.   In  such cases, the attacker will effectively ``pass''
the HTTP_REFERER validation test[6], and  the  remainder  of  the
FormMail script will then be executed.

Even though it is clear that the simplest and easiest way to cir-
cumvent the HTTP_REFERER check in FormMail  is  simply  to  avoid
including  any  Referer: header in the HTTP request, for the sake
of completeness we would also like to  note  some  other  methods
whereby this same check could be circumvented even in programming
contexts[7] where omission of Referer: headers may  be  difficult
or impossible to achieve.

Specifically, it should be noted that the Perl regular expression
matching attempt:

     $ENV{'HTTP_REFERER'} =~ m|https?://([^/]*)$referer|i

is not left-anchored prior to the  https?:  scheme  specification
nor is it right-anchored after the $referer domain name.

The lack of left-anchoring prior to the https?: scheme specifica-
tion portion of the regular  expression  allows  an  attacker  to
``pass''  this simple-minded HTTP_REFERER validation test as long
as the HTTP_REFERER value (set from the HTTP Referer: header)  is
some  URL  containing a match for the regular expression anywhere
within its entire length.

An attacker may easily exploit this  lack  of  left-anchoring  by
simply  loading,  and then submitting an HTML form to the desired
FormMail CGI from the attacker's own local  web  server  using  a
extended `spoof' URL which contains a substring matching the reg-
ular expression somewhere within  the  entire  URL  string.   The
matching  substring may be presented as part of the right context
of the complete URL, and specifically within a portion of the URL
that  will,  by  convention,  be ignored by many/most web servers
when loading a page corresponding to the given URL.  For example,
the following URL:


if  included  as  the  URL  in an HTTP GET request will typically
result in the HTTP client receiving a copy of the same  web  page
that would have been obtained if the requested URL had been just:


because a typical web server will simply ignore the trailing por-
tion  of the URL past the question mark.[8]  Typical HTTP clients
on the other hand, if asked to perform such a GET operation, will
do  so  (with  the help of the relevant web server) but will then
preserve the entire original request URL and will  later  present
that  as  the  Referer:  value, when and if some HTML form on the
page is the subject of a submit operation.

The HTTP client's preservation of the entire URL,  including  the
trailing  `spoof'  substring, allows most typical HTTP clients to
trivially pass FormMail's simple-minded  HTTP_REFERER  validation
test even if the attacker has neither built nor obtained any HTTP
client software that allows for  suppression  of  Referer:  head-
ers[9], and even if he is writing his own attack software in some
language (e.g. Javascript) that otherwise makes  the  implementa-
tion of attacks on web CGIs particularly easy and convenient.

The  lack  of  right-anchoring  after the $referer portion of the
regular expression may also be exploited by an  attacker  wishing
to  create  a  modified  FormMail  HTML  submission form on a web
server of his own choosing.  This  may  be  more  difficult  than
exploiting  the  lack  of left-anchoring however, and may perhaps
only be achievable with the aid of some cooperative  DNS  server.
Given the availability of such a server however, a DNS `A' record
could easily be defined for an fully-qualified domain  name  such

and  that  `A'  record could be defined with an IP address of the
attacker's choosing.  In this case,  the  attacker  could  easily
load  his  malevolent  locally-installed HTML exploit form (which
has its ACTION= clause set to point  to  the  victim's  FormMail)
into his browser via a URL such as:

The  attacker  could  then  simply  submit  the form and it would
`pass' the simple FormMail HTTP_REFERER validation check.

Note  that  all  three  methods  for   circumventing   FormMail's
HTTP_REFERER  validation remain present in the current (1.9) ver-
sion of the script, i.e.  (1)  complete  omission/suppression  of
Referer:  headers  and  (2)  exploitation  of  the lack of right-
anchoring and (3) exploitation of the lack of left-anchoring.

Once  an  attacker   has   passed   the   easily   circumventable
HTTP_REFERER  validation check, he then has a mostly free hand to
manipulate other CGI (form input) variables in order to direct an
e-mail message of his choice to some selected destination address
or addresses.

FormMail obtains the desired destination e-mail address for  each
transmitted  e-mail  message  from  the  HTTP  client.   The HTTP
client, in turn, is expected to obtain it  from  the  pre-defined
value  of  a hidden HTML form field (recipient) within a form (or
forms) associated with the specific web site/server where a given
instance  of FormMail is installed.  Obviously however, if (as we
have seen above) it is trivial to trick FormMail  into  believing
that  some  attacker-created  form which actually resides on some
arbitrary web server of the attacker's choosing is a  valid  ref-
erer,  then  attackers  can  certainly  manufacture (or simulate)
forms with the recipient form field set  to  any  e-mail  address

These are the conditions which led to earlier reports of FormMail
being exploited, generally by bulk e-mail spammers, as if it were
a  kind of anonymizing open e-mail relay server.  The fundamental
problem was  that  the  HTTP_REFERER  checking  could  be  easily
spoofed,  and  that the pre-1.9 versions of FormMail performed no
validation checking of any kind on the recipient  CGI  parameter.
Attackers  were thus allowed to set this parameter to any desired

Version 1.9 of FormMail incorporated changes whose purpose was to
allow  the  actual  destination  e-mail addresses (i.e. the value
given for the recipient CGI parameter) for any submitted  message
to  be  restricted  by checkingthem against an installer-supplied
list of ``acceptable'' recipient e-mail addresses and/or  recipi-
ent domains.  As noted below however, these changes did not fully
achieve their goal.  That unfortunate  fact,  together  with  the
multiple  flaws  in HTTP_REFERER checking (all of which are still
present in the 1.9 version) imply that even the current 1.9  ver-
sion  of  FormMail can still be used and abused for spamming, for
e-mail harassment, or other purposes neither condoned or intended
by the FormMail installer.

Anonymous Mail Forwarding Exploits in FormMail 1.9

As  noted above, versions of FormMail up to and including 1.8 are
believed to be vulnerable to various security exploits, including
but not limited to creative generation of HTTP header and message
data, leading to an installed FormMail CGI script at  a  targeted
site behaving like an anonymizing open e-mail relay.  At present,
spammers are continuing and increasing their abuse of  such  ear-
lier  versions  of  FormMail,  especially the widely deployed 1.6
version, at various  sites  where  these  earlier  versions  are,
unfortunately, still installed.[10]

This advisory describes various vulnerabilities in version 1.9 of
the FormMail script that may also lead to misuse and abuse of the
script  by  remote  attackers  to  achieve an effect functionally
equivalent to an anonymizing open e-mail relay server.

Note that many, if not most of these exploits were  also  present
in versions of FormMail prior to the 1.9 version, and thus it may
be fairly said that the exploits described herein are not in  any
sense  new  to the 1.9 version.  For the sake of brevity however,
we report these problems as vulnerabilities in the 1.9 version.

The vulnerabilities described herein  may  be  broadly  separated
into the following categories: (1) creative recipient addressing,
(2) exploitation of the email and realname  CGI  parameters,  (3)
other regular expression matching issues, and (4) mail-bombing by
proxy using FormMail.  These vulnerability  categories  are  each
described in separate sections below.

Creative Recipient Addressing

The  preceding  section  noted that FormMail 1.9 suffers from the
same HTTP_REFERER validation flaws as  earlier  versions  of  the
script, thus forcing the prevention of unauthorized use/misuse of
the script to rely entirely  on  the  code  added  in  1.9  which
attempts  to validate client-supplied recipient e-mail addresses.
These added checks contain a number of subtle  and  not-so-subtle
flaws however, any one of which, if exploited, renders the check-
ing code useless and ineffective.

Briefly, the recipient address checking code added in 1.9  merely
attempts  to  ensure  that  each comma-separated substring of the
client-specified recipient string matches  (with  right-anchoring
only, and without case sensitivity) one of a set of strings spec-
ified by the person who installs the FormMail script.  The  array
called @recipients is used to hold these (valid recipient address
or domain) strings and  each  comma-delimited  substring  of  the
client-supplied  recipient CGI parameter string is checked to see
that it matches (right-anchored) at least one of these installer-
specified ``approved'' recipient address or domain strings.

As  long  as  this  check `passes', for any given comma-separated
substring of the recipient value, that substring will be saved in
yet  another  array (@send_to), and later on, all elements of the
``validated'' @send_to array are join'd back together, with comma
separators,  and  the  resulting string replaces the old, unvali-
dated recipient CGI parameter value.  That value  is  then  later
used  (when  writing  e-mail headers to the local mail server) in
the following Perl statement:

     print MAIL "To: $Config{'recipient'}\n";

So, for example, if the installer of the script  had  provided  a
definition of @recipients like:

     @recipients = ('pres\@elsewhere.tld', 'ourdomain.tld');

then all of the following client-supplied recipient addresses, if
given by the HTTP client, either alone or as elements of a comma-
separated  list of recipient addresses, would ``match'' some ele-
ment of the @recipients array definition shown above,  and  would
thus be allowed as valid recipient addresses:

     PRES@elsewhere.tld (See note #1)
     vice-pres@elsewhere.tld  (See note #2)
     user%somewhere.tld@ourdomain.tld  (See note #3)
     user@somewhere.tld(ourdomain.tld  (See note #4)
     user@somewhere.tld(pres@elsewhere.tld  (See notes #2, #4)
     <user@somewhere.tld>ourdomain.tld (See note #5)
     <user@somewhere.tld>user@ourdomain.tld (See note #6)
     <user@somewhere.tld>pres@elsewhere.tld (See notes #2, #6)

Unfortunately, some of the ``acceptable'' strings shown above, if
crafted by an attacker and then used within a  spoofed/fraudulent
HTTP  request may lead to undesirable consequences, i.e. the for-
warding of an associated e-mail message  to  some  recipient  (or
recipients)  having  e-mail  addresses  that  the installer never
intended to allow as FormMail message recipients.

Several notes regarding the example strings shown  above  are  in

  1.  Comparison  of each comma-separated sub-part of the client-
      supplied recipient string is performed without case  sensi-
      tivity.   On systems where the initial (user ID) portion of
      e-mail addresses is  considered  case-sensitive,  this  may
      allow  misuse  of FormMail to send e-mail messages to unin-
      tended recipients having e-mail addresses with  alternative
      case  on  the same system.  Worse however, this possibility
      opens up a hole that might perhaps allow a remote  attacker
      to misuse an installed FormMail script in a way that avoids
      immediate detection by any local user or administrator.  We
      will return to this point below.

  2.  In  fairness  to  the FormMail author, the README file sup-
      plied with FormMail version  1.9  explicitly  and  strongly
      suggests  that installers should prefix any and all full e-
      mail addresses they include within the  definition  of  the
      @recipients  array with the up-caret (^) character, thereby
      causing subsequent regular expression  matching  for  those
      strings  to  be anchored both on the left and on the right.
      Following that suggestion  would  certainly  eliminate  the
      potential  exploits  noted  above  that refer to this note.
      Anyone following the FormMail author's advice  with  regard
      to  1.9  installation  would have written their @recipients
      definition as follows:

      @recipients = ('^pres\@elsewhere.tld', 'ourdomain.tld');

      rather than the way it  was  written  further  above,  thus
      eliminating  such  obvious potential problems as being able
      to trick FormMail into sending unauthorized e-mail messages
      to  vice-pres@elsewhere.tld.  As we have already noted how-
      ever, even when each and every element  of  the  installer-
      defined  @recipients  array is set to a full e-mail address
      (as opposed to merely a domain name) and even when each  of
      the  e-mail  addresses  in  question  is left-anchored, the
      check for correspondence between client-supplied  recipient
      addresses  and the installer-defined set of allowed recipi-
      ent addresses is performed in a  case  insensitive  manner.
      We will return to this issue below.

  3.  Although  the  recipient  parameter provided to FormMail by
      the HTTP client will  have  newlines  and  carriage  return
      characters,  if  present, removed by FormMail, and although
      the recipients string is separated into a set of comma-sep-
      arated  substrings  before the recipient address validation
      occurs, no other validation of the form, format, or  syntax
      of  the  recipient  address(es)  is performed.  This leaves
      open the possibility of  using  the  old  and  widely-known
      Sendmail  percent  hack[11]  form  of e-mail addressing, at
      least in cases where one or more of  the  elements  of  the
      @recipients array are just domain names, as opposed to full
      e-mail addresses.

      To understand fully why use of the percent hack  is  almost
      guaranteed to work in such cases, one must understand that:

         o FormMail is  designed  to  work  in  conjunction  with
           either  Sendmail or with some work-alike program, such
           as Postfix, and we may thus assume that whatever  mail
           server  FormMail is hooked up to will almost certainly
           be one that does support  the  percent  hack  form  of

         o In  normal  (non-exploit)  operation,  the mail server
           resident on the  same  host  as  the  FormMail  script
           itself  will  (unless  the  administrator  has botched
           either his Sendmail configuration or his FormMail con-
           figuration)  accept  all  ``locally generated'' e-mail
           messages  coming  out  of  the  FormMail  script   and
           addressed  to any e-mail address whose @domain part is
           the same as of any one of the domains  listed  in  the
           @recipients  array.   Thus, in the preceding examples,
           we can usually be sure that the local mail  server  on
           the FormMail host will not disallow or reject any such
           ``locally-generated'' e-mail message that is addressed
           to  user%somewhere.tld@ourdomain.tld  because  it will
           see  that  the  domain  portion  of  this  address  is
           ourdomain.tld.   That alone will probably be enough to
           satisfy Sendmail that it should accept (and, if neces-
           sary,  forward) the mail message in question.  Also, a
           typical Sendmail installation, even a modern one, will
           usually not itself object to any kind of forwarding of
           any ``locally-generated'' e-mail message to any  other
           domain  or site, because it is typical to assume (when
           configuring Sendmail) that ``local''  e-mail  origina-
           tors  can  be fully trusted, at least to send outgoing
           e-mail to other sites.  (Note that FormMail is  acting
           in  the  role  of a ``local'' and trusted user in this
           case.)  So an attacker really only needs to  get  past
           FormMail's  check  on  HTTP_REFERER (which, as we have
           seen, is trivial to do) and then, if he can  also  get
           past  FormMail's  check  of the right-most part of the
           recipient  address  string(s)  against  the  @referers
           array  he  will  be  able  to  send e-mail messages to
           essentially any e-mail address anywhere on the  Inter-
           net.   As illustrated by the example above, use of the
           percent hack form  of  e-mail  addressing  allows  the
           attacker to get past the latter check.

  4.  RFC 2822, like RFC 822 before it, specifies that within the
      text of so-called structured mail headers (e.g.   To:)  any
      string  enclosed within matching left and right parenthesis
      shall be taken as being  purely  commentary  material,  and
      shall  be ignored.  Thus, if an attacker provides a recipi-
      ent string of the form:


      and if that  string  passes  the  (right-anchored)  regular
      expression  matching check (i.e. matching at least one ele-
      ment of the @recipients array),  then  a  To:  header  line

           To: user@somewhere.tld(ourdomain.tld

      will  be  generated by FormMail and passed to Sendmail.  In
      such a case, Sendmail should take  everything  between  the
      left parenthesis and the corresponding right parenthesis as
      a comment, thus leaving it with only the user@somewhere.tld
      address to act on.  However in this case, there is no clos-
      ing right parenthesis before the end of the header line, so
      this would appear to be a case where the actual behavior of
      the mail server cannot be predicted.  In practice  however,
      both  Sendmail  and Postfix helpfully and implicitly supply
      the missing closing right parenthesis themselves, with  the
      result  being  that  the  (ourdomain.tld portion of the To:
      header   is   in   fact   ignored,   leaving    only    the
      user@somewhere.tld part to define the actual e-mail recipi-
      ent address.

  5.  For a client-supplied recipient string of the form:


      Sendmail will subsequently be fed  the  corresponding  mail

           To: <user@somewhere.tld>ourdomain.tld

      and  when  such a header is supplied to Sendmail along with
      Sendmail's -t  (take  recipient  address(es)  from  message
      headers) option, reports indicate that Sendmail will send a
      copy of the message to user@somewhere.tld, and that it will
      then ignore the remainder of the header line, i.e. the part
      past the right (closing) angle bracket.  (This is  in  fact
      entirely consistent with what the mail header parsing rules
      contained in RFC 822 and 2822 would indicate  should  actu-
      ally happen in such a case.)

  6.  For a client supplied recipient string of the form:


      it  would appear clear that if ourdomain.tld is included in
      @recipients, then such a string will pass FormMail's recip-
      ient  address acceptability check, and later, when Sendmail
      is fed:

           To: <user@somewhere.tld>user@ourdomain.tld

      then Sendmail will most certainly send a copy of the  asso-
      ciated    e-mail    message    at   the   very   least   to
      user@somewhere.tld,     but      possibly      also      to
      user@ourdomain.tld.   Reports suggest however that Sendmail
      will ``parse out'' the latter e-mail address and  send  the
      message only to the former address.  Even if the local mail
      server used on a given victim server is one taht will parse
      the  header  shown  above  and  then  send  to  both e-mail
      addresses, an attacker could potentially choose some infre-
      quently-  or  never-monitored  e-mail  address (such as the
      traditional nobody user ID) within the targeted domain  and
      use  that  e-mail  address to provide the right context for
      his (spoof) recipient string.  That also will allow him  to
      get past FormMail's recipient address acceptability checks.

Exploitation of email and realname CGI Parameters

As noted in the preceding section,  clever  manipulation  of  the
recipient  CGI  parameter when invoking FormMail 1.9 can allow an
attacker to bypass the recipient address checks  imposed  by  the
installer's  definition  of  the  @recipients  array, at least in
cases where the installer has failed to define elements  of  this
array  to  complete  e-mail addresses (i.e. when one or more ele-
ments of the array is just a domain name) and  when  and  if  the
installer  has  failed to left-anchor (with `^') each full e-mail
address within the @recipients array definition.  Even  in  cases
where  all  elements  of  the  @recipients  array are full e-mail
addresses and where these are all left-anchored, an attacker  may
perhaps  still  be  able  to  bypass FormMail's recipient address
checks by exploiting various  weaknesses  in  FormMail's  regular
expression matching code, as we will show in the next section.

Clever  bypassing  of  the  checks applied to the comma-separated
substrings of the recipient CGI parameter may however not even be
necessary  so  long as the attacker is willing to supply cleverly
constructed values for the email and/or realname CGI  parameters,
and  so  long as the attacker is willing to allow one copy of his
e-mail message to go to some ``permitted'' recipient address,  in
addition to some other attacker-specified list of addresses.

The  email  and  realname  CGI  parameters  may undergo even less
scrutiny  by  FormMail   than   the   comma-separated   recipient
substrings.   In  fact  the email and realname CGI parameters may
undergo no validation whatsoever.  (The realname  parameter  most
certainly  does  not  undergo  any  validation  whatsoever within
FormMail, and the email parameter will not undergo any validation
as  long  as  it is not listed as a required field in the list of
required form fields that is itself initialized from the  client-
supplied  value  of yet another hidden form field.  Given that an
attacker, either a determined one or a hurried and careless  one,
will  most  probably  set  the  value of the required hidden form
field to null or no value, we will just simplify the remainder of
our presentation by assuming, from here forward, that neither the
email CGI parameter nor the realname CGI  parameter  undergo  any

One  critical  additional  point to note here is that neither the
email CGI parameter value nor the realname  CGI  parameter  value
are in any way ``cleaned up'' by FormMail before they are printed
to the local mail server.   Specifically,  the  values  of  these
variable  do not have carriage returns or newlines removed before
they are given to the mail server.

Once they have been supplied by the HTTP client, both  the  email
and realname CGI parameter values are printed, verbatim and with-
out filtering, to the local mail server via  the  following  Perl

     print MAIL "From: $Config{'email'} ($Config{'realname'})\n";

One's first thought upon seeing this statement is that  the  lack
of  filtering or validation applied to the email and realname CGI
parameters cannot possibly be harmful, given the  benign  context
(i.e.  a  From:  header)  within  which these values will appear.
That thought would be misleading however, because of the lack  of
newline removal for these parameter values.

Because an attacker can embed newlines in either or both of these
CGI variable values, he can also effectively change  the  context
in  which  the  remaining  (rightward) characters of either value
appear to the local mail server.  Specifically, an attacker could
set the value of the email parameter to some string such as:

     IGNORED\nCc: user@somewhere.tld,...

where  \n  represents  a  newline  character.  This rather simple
trick provides the attacker with access to a self-generated  Cc:,
Bcc:,  or  (secondary)  To:  header context which, once achieved,
provides the attacker with an avenue to  direct  the  local  mail
server  to  send the attached message to some arbitrary set of e-
mail addresses, in addition to whatever  address  may  have  been
specified  (via the recipient CGI parameter) for inclusion in the
earlier To: header.

As should be apparent from the Perl print statement shown  above,
this  same  context  shift (achievable via embedded newlines) may
also and equally be exploited via clever construction of a  suit-
able  attacker-supplied value for the realname CGI parameter.  In
this case however, the attacker would need to take care  to  also
escape  from  the  confines  of  the  paired parentheses that the
script will supply to enclose the realname value.  Given that the
realname  parameter  value  will  appear in the mail headers sur-
rounded by a pair of open and close parenthesis, the  ``smuggling
in''  of  additional  recipient  addresses  via  the realname CGI
parameter requires the attacker to  include  some  strategically-
placed  parenthesis of his own in the value he passes to the vic-
tim web server for the  realname  parameter.   For  example,  the

     IGNORED)\nCc: user@somewhere.tld\nX-Ignore: (

could  be  supplied  by an attacker as the realname CGI parameter
value, thus  closing  the  already-opened  SMTP  header  comment,
escaping  to,  and  creating  a  new  (Cc:) e-mail header context
(which is then filled with  victim  e-mail  addresses),  escaping
again to another new e-mail header context, and then finally sup-
plying a open parenthesis to match the closing one that  will  be
supplied by the Perl print statement within FormMail.

Last  but  by  no means least, it should be noted that vulnerable
FormMail installations may be less than ideal as a  vehicles  for
distributing  e-mail  messages,  either unsolicited or otherwise,
due to FormMail's rather inconvenient (for the spammers) habit of
appending  its  own  unique legend just ahead of the body text of
any  given  mail  message  that  it  forwards.   FormMail  always
prepends  a  set  of body text lines having the following general
form to each e-mail message it passes to the local mail server:

  Below is the result of your feedback form.  It was submitted by
  (sender address) on date/time stamp

This additional leading body text would appear to be annoying  to
spammers who would much prefer to have the text of their own mes-
sages appear at the very start of the  message  body  text.   (We
assume  that  this  spammer-annoying aspect of FormMail is one of
the reasons, if not the primary reason that spammers have  gener-
ally shown a preference for using open mail relays, as opposed to
open FormMail scripts, for sending their messages.)

Unfortunately however, given that  the  email  and  realname  CGI
parameters  of  FormMail  may  contain  embedded  newlines, it is
apparent that either of  these  parameters  may  be  set,  by  an
attacker, to a value which includes not only additional recipient
addresses, but also additional mail headers and  additional  ini-
tial  message body text of the attacker's choosing.  For example,
the email parameter could be set to:

     \nCc: user@somewhere.tld\nSubject: $$$\n\nMAKE MONEY FAST!!!

thus  causing the text "MAKE MONEY FAST!!!" to appear in the out-
going message as the very first line of the message's body  text.
Furthermore,  a  value  such as the one shown just above could be
followed by arbitrarily many additional newline characters,  thus
pushing  the  FormMail  supplied  legend  text far down below the
attacker's desired subject header and initial message  text  (and
perhaps  even  entirely off the `front page' of what the messages
recipient will see when he first looks at the received  message).

This  tactic  may  of  course  be  applied with essentially equal
effect to either the email or realname  parameters,  except  that
the caveats mentioned above concerning the balancing of parenthe-
sis would apply in the  case  of  manipulation  of  the  realname

These  possible  tactics  for  ``hiding''  the otherwise spammer-
annoying FormMail leading body text are not,  unfortunately,  the
only  ones possible.  As one careful early reviewer of this advi-
sory noted, the vulnerability which allows an attacker to include
newlines  in  the  email an/or realname CGI parameters might also
open up an avenue whereby the FormMail-supplied leading body text
could be effectively removed from the view of a message recipient
via the careful construction of MIME e-mail headers which achieve
that exact effect.  (This design of an exploit making use of this
approach is left as an exercise for the reader.)

Other Regular Expression Matching Issues

We have noted above several ways of bypassing FormMail's attempts
to  validate  a  client-supplied  recipient string, where most of
these methods rely  on  various  obscure  and  not  widely  known
aspects  of  e-mail address parsing rules.  These are by no means
the only ways to circumvent these  recipient  address  validation
checks  however.   These checks may also be bypassed via at least
three different exploits relating to FormMail's  use  of  regular
expressions  for e-mail address matching/validation.  These addi-
tional exploit techniques are described below.

The  first  regular  expression  exploit  we  present  offers  an
attacker  an  easy  opportunity  to get past FormMail's recipient
address checking tests, although perhaps in a way  that  will  be
quickly   detected  by  an  alert  local  administrator  (of  the
exploited server).  Note that due to  the  flow-of-control  logic
used  within  FormMail,  an attacker must get past these tests at
least once, or else no e-mail messages will be sent at all.

Consider the case where the local FormMail installer provided the
following definition for the @recipients array:

     @recipients = ("^john\@our-server.tld");

Given  that the string enclosed within the double quotation marks
will in fact be used, verbatim, as a regular expression within  a
Perl regular expression match, and given that within such regular
expressions, each period character actually stands for a  single-
character  wild  card character, an attacker could supply a value
for the recipient CGI parameter such as:


In such a case, unless by some  extremely  remote  chance,  there
happens to be another server on the same local network whose non-
qualified node name is our-serverXtld, the mail message  sent  by
the  attacker through FormMail to the specified recipient address
(and perhaps also to some additional set of  recipient  addresses
smuggled  in  via  the email and/or realname CGI parameters) will
almost certainly generate a undeliverable bounce message for  the
non-existent john@our-serverXtld address.  Where will this bounce
message go?

We would hope that the  undeliverable  bounce  message  would  be
directed  to  some responsible local administrator who would then
quickly realize that the game is afoot, and that  somebody  some-
where  is  presently  attempting to exploit the locally-installed
copy of FormMail, but in point of fact this is unlikely to occur.

What  is  clear  is  the the bounce message, by convention and by
SMTP standards, will be sent to the envelope sender address  that
was  attached  to  the original e-mail message that generated the
bounce.  What will the original envelope sender address be?

Because FormMail  itself  generated  the  original  message,  and
because  FormMail  itself  was executed as a child process of the
local web server, the original envelope sender address will typi-
cally  be  whatever  local  user-ID  the  local web server is run
under, or rather, whatever local user-ID it changes to  after  it
starts up.

For  typical  Apache  installations,  the account in question is,
quite often, the local nobody account.  That account name is,  in
turn,  quite often and quite typically aliased (in the local mail
server's aliases file) to /dev/null, in other words to the obliv-
ion black hole.

The  implications  here  should  be  apparent.   An  attacker who
attempts to exploit FormMail may be easily able to escape immedi-
ately  detection  by  local  administrators  simply by exploiting
FormMail's inattention to the important detail  that  within  the
context  of  Perl regular expression matching, periods mean some-
thing other than literal periods.  Exploitation of this  inatten-
tion  to  detail  may  allow  an  attacker to ``pass'' FormMail's
recipient address check in a very  stealthy  fashion.   Once  the
attacker has gotten past the recipient check, at least once, then
he may exploit  the  email  and/or  realname  vulnerabilities  of
FormMail (described above) to also direct copies of his mail mes-
sage to other targeted e-mail addresses.

Other, perhaps even more interesting variations on this theme are
also  possible,  and are perhaps even more directly dangerous.  A
FormMail installer who had defined his @recipients array to:

     @recipients = ("ourdomain.tld");

in order to allow FormMail to be employed to  send  mail  to  any
user of the ourdomain.tld domain might later be unpleasantly sur-
prised to begin  receiving  spam  complaints  from  somewhere.tld
users  when  some  miscreant finally figures out that a recipient
address such as:


passes the (right-anchored only) regular expression match against
ourdomain.tld  with  flying colors, only to subsequently have its
parenthesized portion treated as a (non-significant)  comment  by
the local RFC-conforming mail server.[14]

Yet  another aspect of the weakness of FormMail's regular-expres-
sion based attempts to validate recipient address strings is  its
total  insensitivity to important lexical aspects of domain names
themselves, in particular, domain label boundaries.

FormMail installers who have elected to use one  or  more  domain
names  in  their  definition of the @recipients array may be dis-
mayed to learn that the lack of left-anchoring in FormMail's reg-
ular expression matching, together with FormMail's inattention to
the importance and significance of domain  label  boundaries  may
lead  to exploitation of a locally-installed FormMail, by outside
spammers, to spam users in other domains whose own  domain  names
have right-anchored substrings which just happen to exactly match
the local domain name, even though there is  otherwise  no  rela-
tionship between those other domains and the local domain.

For example, the following @recipients array definition:

     @recipients = ("");

clearly  allows  the  local  FormMail script which contains it to
direct FormMail-generated e-mail messages to various users having
e-mail  addresses directly within the domain.  However what
may be less clear is that it also allows FormMail-generated  mes-
sages  to  be directed to persons having e-mail addresses within,
for example, the domain.   More  troubling  is
that it also allows FormMail-generated messages to be directed to
any  person  having  an  account  in  the   (clearly   unrelated) domain.  This problem arises because FormMail is
not astute enough to understand that,  for  example,  the  domain
name  is  related to the domain while the
domain name is  entirely  unrelated.   Thus,  an
instance of FormMail installed on a web server belonging to
could potentially be used to spam users in  the

Lastly,   as  we  noted  earlier,  one  method  of  circumventing
FormMail's  attempt  to  validate  the  recipient  CGI  parameter
against  elements  of the installer-supplied @recipients array is
to simply use alternative case for the user  ID  portion  of  the
client-supplied  recipient  e-mail  address.   At the very least,
this might allow an attacker to use FormMail to  send  an  e-mail
message   to,  for  example,  a  user  whose  e-mail  address  is
JOHN@localhost.tld even though the  installer  only  intended  to
allow FormMail messages to go to the user whose e-mail address is

This fact alone may  be  properly  viewed  as  being  essentially
insignificant.   At worst, the case insensitivity of the FormMail
recipient address checks would  seem  to  allow  misdirection  of
FormMail messages to different (and unintended) users of the same
target recipient system where some  other  valid  and  authorized
FormMail message recipient also has an account.

Recall  however  that the logic of FormMail demands that at least
one of the  comma-separated  substrings  of  the  client-supplied
recipient  CGI  parameter value must in fact `pass' the recipient
address validation check.  Otherwise no e-mail  message  will  be
sent,  regardless  of  whatever  other  clever  manipulations  an
attacker might have undertaken.

Exploitation of the case-insensitivity of the  recipient  address
checking  code  may  provide yet another means for an attacker to
pass the recipient address check, at least  once,  thus  insuring
that his desired e-mail message will in fact be sent by FormMail.
Furthermore, it may allow  the  recipient  address  check  to  be
bypassed  even  as it also allows the attacker to avoid immediate
detection of his activities, either by  any  authorized  FormMail
message recipient or by any local administrator.

For example, let us suppose that the @recipients array was previ-
ously defined by the installer as follows:

     @recipients = ("^john\@our-server.tld");

Based on the other vulnerabilities noted above, an attacker could
easily  spoof  his  way  past the HTTP_REFERER check and he could
then provide some clever values for either the email CGI  parame-
ter  or  the realname CGI parameter, or both.  Those values could
induce FormMail to send a desired e-mail message  to  some  addi-
tional  e-mail  recipient  addresses,  above  and beyond whatever
address may have been provided by the attacker as the client-sup-
plied  recipient  CGI  parameter  value.  But even if he does all
this, the attacker must still get past the script's checks on the
recipient  value,  at  least once, in order to induce FormMail to
send any e-mail messages at all.

To get past the checks on  the  validity  of  the  recipient  CGI
parameter,  the  attacker  might  set this parameter to the value
JOHN@our-server.tld.  This would cause  the  recipient  check  to
pass,  once, and that in turn would enable the script to continue
further in its processing of the HTTP request, whereupon  any  of
the   several   other  FormMail  vulnerabilities  could  then  be
exploited.  In such a case however, the local mail  server  would
also  attempt  to send a copy of the attacker's message to the e-
mail address JOHN@our-server.tld.  What then?

In the most common case, i.e. where our-server.tld is in fact the
local  domain,  and  where the mail server providing mail service
for the local domain is either Sendmail or Postfix, the  attacker
will  typically  not be able to hide his activities via this sort
of case-sensitivity exploitation because the local mail server (-
Sendmail or Postfix) will actually treat the user ID portion of a
local e-mail address in a case-insensitive manner.  Thus, even if
the  attacker  tricks the FormMail script into attempting to send
an e-mail message to JOHN@our-server.tld that message will  still
be  delivered to the john@our-server.tld mailbox.  The local john
user will thus be alerted that the local FormMail script is being
used,  and possibly abused, and quick remedial action may then be
taken to halt further abuse.

If however the specific mail server that  provides  mail  service
for  the  our-server.tld  domain treats local user IDs in a case-
sensitive manner, then the user ID john may exist, and may accept
incoming  e-mail, even though the user ID JOHN does not exist and
does not accept e-mail.

In this case, any message sent to the JOHN@our-server.tld account
will bounce as undeliverable.  Where will it bounce to?

As noted previously, the message should be, and typically will be
bounced back (along with an undeliverable notice) to its envelope
sender  address.   And as was also previously noted, the envelope
sender address will almost invariably be the local user ID  under
which both the local web server and any CGIs that it invokes run.
That account, quite often, is the local nobody  account,  and  e-
mail for the local nobody account is, as often as not, aliased to
/dev/null.  Thus,  if  the  attacker  arranges  to  ``pass''  the
FormMail  recipient  address validation test by changing the case
of the user ID portion of some known authorized recipient  e-mail
address,  and  if  the  alternatively-cased  recipient address is
itself undeliverable, then this may represent an opportunity  for
the  attacker.   Specifically, it may allow the attacker to trick
FormMail into believing that it has received at least  one  valid
recipient  address  even  though the message sent to that address
will first be bounced as undeliverable  and  then,  subsequently,
will  disappear,  quietly  and  conveniently,  down a black hole,
without alerting any local end-users or any local  administrators
on the exploited system that exploitation is occurring.

It  should additionally be noted that even in cases where the web
server itself is run under some account  other  than  the  nobody
account,  the  account  that  the web server is in fact run under
will often  and  typically  be  one  for  which  incoming  e-mail
messages,  including bounces, are dumped into a black hole.  Fur-
thermore, even for web server execution  accounts  that  are  not
aliased  to  /dev/null, local administrators may not be expecting
any incoming e-mail for the web  server  execution  account,  and
thus,  any  e-mail that does arrive for that account may be moni-
tored only rarely or perhaps never.  Such a situation is  exactly
what  an  attacker  wishing  to  escape immediate detection would

In summary, it may safely be said that the case insensitivity  of
the  FormMail  recipient  address checking code may open up addi-
tional possibilities for quietly covering up abuse and  exploita-
tion of the other FormMail security flaws detailed herein.[13]

Mail-Bombing by Proxy Using FormMail

Although  exploitation of installed FormMail scripts for spamming
purposes is far and away the most likely scenario involving  mis-
use  and  abuse of FormMail, a desire for completeness compels us
to note some additional ways in which typical FormMail  installa-
tions may be abused to cause harm or annoyance to others, even if
only indirectly.

In general, any Internet miscreant may easily flood any  Internet
e-mail  account  of  his choosing by simply sending a flood of e-
mail messages directly  to  that  target  account.   This  direct
approach is however known to be a good way to have one's outbound
e-mailing privileges revoked in short order.

Being aware of this fact, many Internet miscreants bent  on  per-
forming  an  act  of  mail  bombing against a given target e-mail
account will instead elect to do so  only  indirectly,  employing
some  intermediary agent or system that can be induced to send e-
mail messages to arbitrary attacker-specified  e-mail  addresses.
To  the extent that the intermediary prevents the final victim of
the mail bombing from easily  learning  the  identity  and/or  IP
address  of  the mail bomb originator it will be seen as a poten-
tially useful tool for a stealth mail bomb attack.[15]

Given these facts, together with the multiple  FormMail  vulnera-
bilities  described above, it should be immediately seen that any
installed instance of the FormMail script  may  be  employed,  in
various  ways,  as part of a stealth mail bombing attack directed
against an arbitrarily selected target e-mail address.

It has certainly been shown above that FormMail may be induced to
send  arbitrary  messages  to arbitrary target addresses in a way
which prevents the final recipient  from  being  able  to  easily
determine  the IP address of the actual message originator.  This
fact alone could provide the basis for  a  stealth  mail  bombing
attack.   Additional  possibilities  for  such attacks, involving
FormMail, may also exist however.

For example, if FormMail is being employed on a given web site in
conjunction  with  an e-mail auto-responder of some kind, then it
may be possible for an attacker  to  repeatedly  invoke  FormMail
while  setting  the  email CGI parameter to the e-mail address of
his intended victim.  The victim in  this  case  will  receive  a
flood  of ``auto-responses'' for messages that he himself did not
originate, and these auto-responses may (and  quite  often  will)
contain  no indication of the IP address that originated whatever
message or messages have triggered the auto-responder to  send  a
response message.  Note also that even for a relatively ``smart''
auto-responder that makes it a point to attach the e-mail headers
of  each  original triggering e-mail message to each of the auto-
response messages it generates, the trace information provided by
such  headers will lead back only as far as the web server on the
system that hosts the FormMail script.  That information will  of
course  be  insufficient  to determine the IP address used by the
actual instigator of the mail bomb.

Because of the above scenario, it is  strongly  recommended  that
FormMail  never be intentionally employed in conjunction with any
kind of e-mail auto-responder.

[1]  The canonical reference for the original `FormMail spamming'
advisory is:

Note  that  even earlier, reports had surfaced regarding FormMail
and environment variable information leakage:

and a fix was developed for this problem:

A  remote command execution vulnerability was also reported (Aug,
1995) for the 1.0 version of FormMail:

[2] The original report of possible widespread  scanning  of  the
net for vulnerable FormMail scripts may be found at:,3396,s%253D25124%2526a%253D18236,00.asp#story4

[3] The home page for one allegedly ``fixed'' version of FormMail
may be found at:

                              - 20 -

An  entirely  separate ``fixed'' version of FormMail may be found

Unfortunately, neither of  these  security-enhanced  versions  of
FormMail address all of the security issues raised herein.

[4]  Inexplicably,  even though versions of FormMail prior to 1.9
are known to be exploitable (as what amounts to anonymizing  open
mail  relays)  the  author of this script continues to distribute
several of his earlier, insecure versions of the script (for  use
with/on  various versions of MS Windows) via his web site and the
FormMail home page.  This will naturally tend to contribute to  a
worsening  of  the  existing  global problem of insecure FormMail
installations, over time.

[5] We use the term anonymized herein to  indicate  that  the  IP
address  of the actual message origination point will not be pre-
sent in any of the e-mail Received: headers contained in the mes-
sage  themselves.   This  lack  of  tracing  information makes it
essentially impossible for a message recipient to  determine  the
actual  origination  point,  at  least not without the aid of the
administrator of the server that hosts the  FormMail  script  and
not  without a careful search of log files by that administrator.

[6] The lynx web browser provides  the  -noreferer  command  line
option to achieve this exact effect.

[7]  Javascript,  in  particular,  implements a submit() built-in
primitive that can be used to simplify attacks on web CGIs.   The
authors  have found no way to induce Javascript's submit() primi-
tive to suppress the inclusion of a Referer: header in  the  HTTP
request generated by a call to submit() however.

[8] There are, of course, other ways to cause typical web servers
to ignore some rightward part of a  complete  URL.   The  forward
slash character (`/') can also be used to achieve the same effect
when the portion of the URL to the right of the relevant  forward
slash  can  be located by the relevant web servers and when it is
an ordinary file (as opposed to a directory).

[9]  There are, of course, other ways by which one could  arrange
for  Referer:  HTTP headers to be suppressed, the most obvious of
which is to make use of any of the  Internet's  many  anonymizing
HTTP proxy servers.

[10] One of the authors of this advisory (Guilmette) is currently
maintaining a list of the IP addresses of  such  sites  for  spam
blocking purposes.

[11] Please see:

                              - 21 -

for a brief description of the traditional (if non-standard) per-
cent hack e-mail addressing notation.

[12] Of course, different operating systems have  different  con-
ventions and practices with regards to the case sensitivity... or
lack thereof...  of local user IDs.  It should be  noted  however
that  FormMail  is most frequently installed on UNIX or UNIX-like
systems, and that these systems do, in virtually all cases, treat
local  user  IDs  as  being case sensitive, thus allowing for the
possibility that there might be a user whose ID is john and  also
another user whose ID is JOHN, both on the same single system.

[13]  Webmasters  may also wish to reconsider the advisability of
running web servers  under  accounts  whose  incoming  e-mail  is
either sent to /dev/null or ignored.  It may actually be wiser to
select some account other than the nobody account to  run  a  web
server  under,  and  then  to alias that other account to root or
some other frequently-monitored local administrator address.  The
nobody  account should more probably be preserved as an effective
e-mail alias  for  /dev/null  however,  as  there  are  certainly
instances  in  which you really don't want any bounces, no matter

[14] See RFC 2822, especially  its  discussion  of  parenthesized
comments and e-mail address syntax.

[15]  An indirect mail bomb attack against a given e-mail address
may be easily undertaken simply by sending a large number  of  e-
mail messages to some non-existent and/or otherwise undeliverable
e-mail address on some specific third-party  intermediary  system
with the envelope sender (i.e. bounce back) e-mail address set to
the e-mail address of the intended victim.  Such an indirect mail
bombing  via  bounces  attack  is  not  at  all stealthy however,
because in the vast majority of cases the attacker's  IP  address
will  be  shown  clearly in the Received: headers of the messages
that triggered the bounces, and these in turn will  typically  be
included in the bounce messages received by the final victim.

                              - 22 -


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC