0

We have a user email that we think is under an backscatter attack. We can find no evidence of the account being compromised. The user also states they have not sent out any of the emails they are getting back. In our system, when an email gets delivered to a users mailbox, the logs will show a line like this one:

LOCAL(username) delivered: Delivered to the user mailbox

What I find interesting is that based off of the number of bouncebacks they are saying they are getting, it does not line up with how many of the lines above that appear in the logs, which would equate to the number of emails being returned to the inbox. Any thoughts on this?

1 Answer 1

2

The bounce messages should contain Received headers that show at least some of the servers the message passed through. Email headers are a valuable resource in investigating issues like this. The method to access the headers varies by email client, some of which make it easy to access the message source.

Configuring a strong SPF policy ending in -all like v=spf1 a mx -all should reduce backscatter. However, it does require appropriate policies. You may want to review my policy as example.

It is common for spammers to use a faked sender address in outgoing messages. It is possible that they have harvested your user's email address sometime in the past decade or two.

If the messages are backscatter, you may want to try to contact the administrators that are sending the backscatter. However, it is possible the email is intended to resemble backscatter. The contents of the Received headers should help in determining which is which.

Received headers are added to the top of the header by each host that handles the message. The IP address in the first header will alway be correct. Unless there is a spoofed header the IP address if present will be correct. Headers above the spoofed header will also have correct IP addresses. Besides the IP address there should be the domainname of the sending server. Depending on whether the sending host is correctly configured there may be an additional domainname used in the EHLO/HELO command.

These headers are from a recently received message from Facebook. They use a different domain name in the HELO command than is found by rDNS verification. The second header is from the facebook server that generated the message. (Recipient has been obfuscated, but the rest of the content is unmodified.)

Received: from 66-220-155-140.outmail.facebook.com ([66.220.155.140] helo=mx-out.facebook.com)
    by mail.systemajik.com with esmtps (TLS1.0:ECDHE_RSA_AES_128_CBC_SHA1:128)
    (Exim 4.86_2)
    (envelope-from <[email protected]>)
    id 1bdfwX-0005HR-Mp
    for [email protected]; Sat, 27 Aug 2016 11:54:51 -0400
Received: from facebook.com (c4xYYmwT/TJ03btpEcY4vvyPTWZL08E+gbfjjvUwuTSB8dW6JOUncubaoppFzCkE 10.224.41.31)
 by facebook.com with Thrift id 915685ca6c6e11e69a620002c9da3c98-2a7fcaa0;
 Sat, 27 Aug 2016 08:54:42 -0700

These headers are from a recently received spam message. This host has an incorrect PTR record so fails rDNS validation. The domain in the HELO command does pass rDNS validation. The second header is the message being delivered by a program on the server that sent the spam. The missing domain for the IP address is highly indicative of a spam message.

Received: from [96.30.32.176] (helo=host.sareesbazaar.in)
    by mail.systemajik.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
    (Exim 4.86_2)
    (envelope-from <[email protected]>)
    id 1bdgds-0005gm-C8
    for [email protected]; Sat, 27 Aug 2016 12:39:58 -0400
Received: from bonitto by host.sareesbazaar.in with local (Exim 4.87)
    (envelope-from <[email protected]>)
    id 1bdgdg-0004rU-4n
    for [email protected]; Sat, 27 Aug 2016 11:39:24 -0500
6
  • Great explanation and a great site for future reference on mitigating spam. But I am still perplexed on why I am not seeing the number of bounces that they say they are receiving back actually hitting the inbox. You would think this would be noticable on the server and its not.
    – user53029
    Aug 27, 2016 at 2:29
  • We have an example of a bounceback that was received. It does show the return path and the envelope sender. Immediately under the return path line is a "received from" line with an IP address. I assume this is the source IP of where the email was originally sent. Would that be accurate? Other than that, I do not see any other servers in the received headers.
    – user53029
    Aug 27, 2016 at 2:38
  • @user53029 The IP address will be the sending address. If there is no domain name for the server you can use whois to find out who owns the IP address block for the server. Check a number of messages to see if this is spam (invalid domain names) or backscatter (valid domain names). If the envelope sender is not "<>", then it is not likely backscatter. Bounce messages should have a null "<>" envelope sender to prevent mail loops.
    – BillThor
    Aug 27, 2016 at 17:46
  • SPF with "- all" is a "must" these days and it will help other servers to decide and reject non-legitimate emails. Unfortunately it usually won't stop bouncing emails back to forged email address (with "SPF fail" message)
    – mangia
    Aug 27, 2016 at 17:59
  • 1
    @mangia '-all' was reasonably effective in dealing with backscatter when I added it. It allows servers to block the message during the initial connection before the message has been accepted. Backscatter is generated when the message is bounced after it has been accepted.
    – BillThor
    Aug 27, 2016 at 18:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .