Mail "spamming".

During the last years an increased activity of "mail spamming" has been observed on the Internet. The level of spamming has reached such a degree that actions are being taken against it. Some of these actions force us to act, even if spamming to us is moderate to low.

Some of these actions also require you to pay extra attention to how, from and to where your E-Mail messages are sent. Read all about these caveats on a separate page.

What is Mail spamming?

Mail spamming is the sending of unsolicited E-Mail, mostly in bulk volumes. If you do not see why this is bad start reading John's Quaterman's Matrix news article .

For us mail spamming consists of three different classes:

  1. Some site or spammer sending spam mail through some of our mail relays to the internet (and possible but not necessarily to our users).
  2. Some site or spammer sending spam mail to our users.
  3. Some of our users sending spam mail.

Where are the threats ?

  1. poses the largest threat.
      Some internet Service providers have created a "Black Hole" in which the traffic for known spamming sites can be dumped. Sites which do nothing to prevent being used for spamming might end up in the "Black hole" and you certainly do not want us to end there.
  2. is of course the most annoying to our mail users.
  3. is forbidden by our deontological rules.

What have we (=system admins) done ?

Against being used as spam relay :

Our mail relays are properly configured to deny any relaying attempt.
Moreover, additional configuration is set up as a second line defense to avoid/minimize abuse:
  • Our mail relays never accept mail from some IP numbers; we use:
    • RBL (MAPS Realtime Blackhole List)
    • DUL (MAPS Dial-up User List)
    • RSS (MAPS Relay Spam Stopper)
    All three lists are avaliable from the MAPS (the Mail Abuse Prevention System) project. This information is checked using DNS. ( is an unofficial DNS secondary for MAPS RBL.)

  • Our mail relays only accept mail:
    • from our own domain (
    • or to our own domain
    • from our other domains
    • or to a site for which we act as MX relay
  • Moreover mail sent to us:
    • must come from a valid domain.
      (This means that the MAIL FROM: line should contain an adres which can be resolved using DNS.)
If you have access to our internal web server, you can have a look at the mails refused by our mail servers during the previous week. The (intended) destination of the refused mails is, if possible, included as arg1=<....>.
(Beware: these are an extract of the sendmails logs, but should be decryptable...)

Against spam mail sent to our users:

  • Mails from some users and domains are rejected:
  • Users and or domains can be restricted when sending mail to us. Note that the information given by remote sites can be forged, and our check is made on the information we get, real and/or forged. If you have access to our internal web server, you can have a look at this access list.
    If you identified a spammer or spam site which frequently harasses our users, you can submit a new spammer site
  • Moreover mails claiming to be from somebody at are only accepted from:
    • machines within the domain
    • from mailling list servers observing the MAIL FROM: <> protocol
    • from a few machines in this exception list
    This check stops all spam claiming to be from our own users ... the from info in an e-mail can easily be forged and therefore this is regular practice in spam mails. This forces our (regular, authorized) users to set up a secure (e.g. ssh) channel to deliver their mail to a SMTP server within our intranet (e.g. when working from outside and sending e-mail to
    This check also stops e-mails originating from within,
    but sent to an outside address, at which they are forwarded/bounced/resent to
    an at address.
    This happens for instance when somebody has an external e-mail address, which is forwarded automatically to his/her e-mail address ... all e-mail sent to this external address from within will be rejected because, at re-entry in our network(s), the sender is somebody at and yet the e-mail comes from a machine outside
    The solution is simple: do not use the external address to reach the person in question, but use his/her internal (at) address.
  • There is spam detection by the amavis/spamassassin packages on Debian Linux.
    Absolutely no message wil be deleted for SPAM suspicion, only headers are added which allow easy detection, classification or deletion later on. The following mail headers are added to messages suspected of being SPAM:
    Subject: [SPAM?] cbs     Kllvyfokbw
    X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at
    X-Spam-Status: Yes, hits=11.6 tagged_above=0.0 required=4.0
    X-Spam-Level: ************
    X-Spam-Flag: YES
    • [SPAM?] is added to the Subject: if hits > 4.0
    • X-Virus-Scanned: allows to check where the spam (and virus) detection was done
    • X-Spam-Status: hits= higher numbers indicate more SPAM probability test= list the tests which hint this mail is spam
    • X-Spam-Level: number of hits as bar, can be used by procmail filter
    • X-Spam-Flag: YES added if hits > 4.0

    Against our users sending spam mail:

      Nothing is done here, except telling you not to send spam mail.

      (In the unlikely case you want to send spam mail, beware since our Unix machines implement ident and your identity migth be detected on the receiving side of your spam.)

    What can you do ?

    • Do not easily give away your general E-Mail address

      Spam lists are collected from various sources of E-Mail adresses.  If your E-Mail adress is nowhere known, you are not going to see much SPAM.

      However you are not going to receive much mail neither and lot's of organisations require your E-Mail address before they give you access.

      You can however extend your E-Mail address with an extension (a string starting with + ). This string is not taken into account to deliver the mail, but will show up in your mail headers. This allows you to:

      • detect from where the E-Mail adress originates
      • allows you to filter out mail to these adresses.

      A small example:

       You want to obtain a software update from an organisation, but their website requires your E-Mail address. Give as E-Mail address:
      If you make abstraction of the string this is your normal E-Mail address. When somebody sends mail to this E-Mail address it will end up in your mailbox but the To: line will be:

      Once you start receiving SPAM mail on this address you know that has leaked this infomation and you can filter these messages out (see below under spam filter). (and depending on your mood start using better services than
  • Hide your E-Mail address

    E-Mail addresses can be (and are) harvested automatically from web pages ... avoid showing your E-Mail address on them.

    Do not only avoid giving it as part of the normal text, but also avoid using it as part of a mailto: or other link ... E-Mail harvesters do not interprete a web page, but just scan (the HTML code) for patterns that are likely to be an E-Mail address. It doesn't matter if such patterns are found in normal text or as part of (HTML or other) tags.

    On the external departmental web server, you can use the cgi-bin to hide your E-Mail address from search (and harvesting) engines, in case you really need or want to provide it.
    Use the links given below as examples of how to obfuscate your E-Mail addresses on web pages.

    • Example 1 Instead of
        <a href="mailto:Voornaam.Achternaam(at)">
        <a href="/cgi-bin/">

      The (at) part is automatically added and thus needs not to be given ... as a matter of fact, it should not be added because this would defeat the whole purpose of avoiding harvesting E-Mail addresses since it would be on the web page again !

    • Example 2 If you need to specify a different domain (i.e. not (at) replace @ by + as in:

        <a href="/cgi-bin/">

      Again, do not use the @ symbol because this would put the real, full E-Mail address back in (the HTML code of) the web page.

      If you want to use a + in an E-Mail address (as described above), you must double the +, otherwise it will be translated into @ ... e.g. V.A++NOSPAM+other.domain will be translated into V.A+NOSPAM@other.domain.

    • You can add extra fields as in Example 3

      • the basic syntax is
      • more than 1 value (e.g. more than one destination E-Mail address) can be given, separating them with , as in
      • more than 1 parameter can be given, separating them with & as in
      • epost, cepost and bcepost parameters correspond to (and are translated into) To:, Cc: and Bcc: fields
      • all other parameters (e.g. subject, body, ...) are transferred unaltered to the resulting mailto: link/redirection.
  • Setup a private spam filter

    The information added to the headers/subject by spamassasin can be used to filter the spam-messages. On Unix systems this can best be done using procmail. Don't forget to check the spam folder(s) once in a while ... because of the heuristic nature of spam-detection there will always be false positives and false negatives !

    See also this page for more information about procmail and how to configure it.

    If you have limited needs or work on a macintosh or windows* you can also use the filtering of your mail client (netscape, eudora, ...)

    More information

    If you want more information on mail spamming check out: