Self-Sending Spam

UPDATE: Check out the second part of this article.

In the past few days, new spam campaigns launched that use the ages old trick called “self-sending spam”, which is about sending spam to you in your name. Spammers probably hope to circumvent your spam filtering with this, and, surprisingly, they often succeed, because people tend to put their own email domain on the whitelist.

What we want to suggest in this article is doing the opposite: blacklisting your own domain. If you add * to the Sender Blacklist, you are defeating spammers easily by turning their own weapon against them. If we assume that all emails legitimately sent in your name are whitelisted in ORF, we can also tell that the rest is not legitimate and thus shall be considered spam.

So how do we know that all legitimate emails are whitelisted in ORF? Here are few things to be considered.

ORF only “sees” emails arriving via incoming SMTP connections. A legitimate scenario when email is sent in your name is when it is outbound. If ORF is installed on the Exchange server, you have probably Outlook clients. These use MAPI to submit outbound emails to Exchange, so there is no incoming SMTP connection and ORF will surely not blacklist these emails, because they are not “seen”. So, if you have a single Exchange server only, ORF runs on that Exchange server and you have Outlook clients only (in Exchange mode), you have nothing to do.

Relaying must be whitelisted. Still the outbound scenario, but with SMTP relaying. In this case, the SMTP client (Outlook in Internet mode, Outlook Express or another internal server) will use SMTP to submit an outbound email to the server where ORF runs, which in turn will deliver the email to the final, external recipient’s server. These connections are seen by ORF and must be whitelisted.
Relaying is controlled either by granting relay rights to IP addresses, or by using SMTP authentication. If you control relaying by IP address, the address of these relay-granted hosts should be added to the Intermediate Host List of ORF (Configuration / Global / Intermediate Hosts).
When using SMTP authentication, make sure that the “Exclude authenticated clients from filtering” checkbox is set on the Configuration / Global / Miscellaneous page. This is the default setting, but in any case, check it.
The above will take care of whitelisting relaying. If relaying is controlled by IP and adding the Intermediate Host List does not help, you can also try adding the IP to the IP Whitelist, although we recommend switching to SMTP authentication more.

Unauthenticated emails. Note that the above will not play well with some solutions that try to send in your name, without using your servers. Typically, websites with “Send this page to…” functionality tend to be broken by this, because they are not authorized to send in your name. When possible, reconfigure these solutions or whitelist them.

SPF. Using SPF can be a good alternative to blacklisting your domain. By publishing an SPF policy, you tell the world what hosts are authorized to send emails in the name of your domain. If you have a single inbound/outbound server only, or all your outbound servers are listed in your MX record, publishing an SPF policy is as easy as adding a TXT DNS record to your domain with “v=spf1 mx -all”. This will tell the world that only the hosts listed in your MX record may send emails in your name. As ORF has an SPF test, it can check inbound email against your policy and if it denies the sender server (in case self-sending spam, it will), the email will be blacklisted right away. You can learn more about SPF at Wikipedia or and use our SPF Check and SPF Syntax Validator tools. Note that with SPF, you can expect the same problems as described in “Unauthenticated emails” above.

Auto Sender Whitelist issues. We got a couple of tech support requests where even though the domain was blacklisted, the incoming email was whitelisted by the Auto Sender Whitelist. In this case, you have the following options:

  • Add your domain to the Auto Sender Whitelist Sender Check Exceptions (Configuration / Tests / Auto sender whitelist, click Settings, select “Check Exceptions” – from ORF 4.2 only)
  • Disable the Auto Sender Whitelist
  • Clear the Auto Sender Whitelist and fix the problem that led to this (see below)
  • Manually remove the related ASWL entries (External Database only, using SQL administration tools) and fix the problem that led to this (see below)

Typically, internal addresses do not end up on the ASWL. When ORF is used on a front-end, in a pre-Exchange 2007 environment, configuration errors may lead to such problem, however. It is because ORF records sender/recipient data of all outgoing SMTP connections (that is, those connections initiated by the local server). When running on a front-end, these include connections used to relay incoming emails to the back-end server. ORF multiple default exception settings to prevent recording this type of relaying, but the best is still to add the back-end server address to the IP-based exceptions (Configuration / Tests / Auto sender whitelist, click Settings, select the Collection Exceptions tab and edit IP-based Exceptions).
Also, you may want to switch the ASWL into “Customized per recipient” mode, in the same dialog. This will prevent using the whitelist entries from someone else.

15 thoughts on “Self-Sending Spam

  1. Prayag

    Hi Peter,

    Some of us can’t use a sender blacklist and neither the SPF is effective.

    Can we expect an external agent from Vamsoft that can take care of this issue once the mails are in and we’re able to apply simple logic like ‘if sender = recipient’ then stop these mails.

  2. John Lorimer

    Actually we have found that adding our internal domains to the ASWL works perfectly to avoid this problem. Interesting thought though to add the domains into the sender blacklist.


  3. Peter Post author


    Why is that you cannot use the Sender Blacklist or the SPF Test for this purpose? Yes, an External Agent could take care of this issue, but I do not clearly see how the above could not work.

  4. Benjamin CUD


    I followed your directions and I believe it will resolve the issue. However, I was using the SPF settings and they were not getting blocked. We currently have a SPF record but emails still come through. Any thoughts?

  5. Prayag

    Without getting into too much details following is the issue,

    Where we run ORF isn’t the point of entry from internet. E-mail makes a hop before arriving to ORF and the previous server mixes in mail from Internet along with mail from other Business Units.

    So a simple sender blacklist (for self domain) would block mails coming from other Business Units who sends with same domain as sender.

    Even SPF is about quite sure to fail as most of the known (and unknown) sending servers are not listed on a already (quite) long SPF record.

    I understand it’s not an ideal condition and that was part of the reason why I had mentioned we’re not able to opt for the simple solution and it’s hurting us real bad with current flood of spam.

  6. Gregg Hill

    If you use an SPF record, it must have a “hard-fail” mechanism at the end, AND you must enable the SPF test at “Both” for the test point.

  7. Prayag


    As I mentioned earlier our SPF record is relatively broken (does not contain hard fail) as we have more than 50+ outgoing gateways and not able to include all of them in SPF record for different reasons.

  8. Peter Post author


    If SPF did not work in the first place, that may be because:

    – Your policy ends with SPF SoftFail and ORF is not configured to blacklist on SoftFail (I believe it does not blacklist on default, but I currently has no access to ORF source code)

    – Some test whitelisted those emails. This can be checked in the logs.

    – DNS issues, e.g. your SPF policy is not visible/different in the internal DNS. Differences between the internal and public DNS are suprisingly common.

    – Other reasons (SPF test not enabled, enabled but at wrong filtering point, Intermediate Host List issues, etc.).

  9. Peter Post author


    Thanks for the explanation, now it makes sense. Indeed, such External Agent is quite easy to be written, basically it’s the following in pseudocode:

    if CommandLineParameter(1) case- insensitively-equals CommandLineParameter(2) then

    We plan to release such agent, however due to the upcoming holidays the ETA is uncertain.

    Otherwise, such email setup is quite unfortunate. When possible, ORF should be deployed in the perimeter MX servers. This gives both best performance, easy configuration, etc.

  10. Pingback: Vamsoft Insider » Self-Sending Spam 2.

  11. Jon

    I have found that whilst my spf records work fine 90% of the time, spammers are starting to send me messages using my address as the to and from with the reply to address being different, the spf record is checking the reply to address domain, and this is not spf protected.

    any ideas?

  12. Boris

    I’ve got study a handful of the articles on your web site now, and I like your style of writing a blog. I included it to my favorites site record and looking at back soon.

  13. led sign

    thanks the useful knowledge article, i study handrul you website .Typically, websites with “Send this page to…” functionality tend to be broken by this, because they are not authorized to send in your name. When possible, reconfigure these solutions or whitelist them.

Comments are closed.