Pentagon Emails Used in Spoofing Scam

Pentagon Emails Used in Spoofing Scam

June 15, 2017 / in Encryption/Security / by Zafar Khan, RPost CEO

The Pentagon is the latest victim of an email spoofing campaign. Pentagon colleagues, partners and vendors are receiving fake emails that appear to be coming from Defense Security Service (DSS) employees. Cyber criminals are most likely trying to hack into company servers and then find a backdoor into the Pentagon server itself.

Most business owners don’t know how easy it is to send a fake email that appears to come from a colleague, vendor or even a public figure. This is one of many common misconceptions about email security and delivery. Over the next three weeks, Tech Essentials will explore these misconceptions…

1. I did not get a bounce notice, so I know my email got there.

This is a false assumption.

Why? Email technologists estimate that more than half of recipient mail servers do not return bounce notification emails.

In case you are curious why some mail servers are configured to not return bounce notices, here is a slightly technical explanation. Spammers often send spam relayed through unknowing ISP mail servers to every conceivable iteration of “”. They will use automated systems to send to ,, and so on. Since most of these are not real addresses, your firm would be sending thousands of bounce notices back to unknowing sending ISP servers if your firm’s mail servers were configured to send bounce notices. The sending ISP servers would then believe your firm’s servers were sending it spam, possibly resulting in your firm’s email servers getting blacklisted. Your firm’s legitimate email would then simply disappear (before reaching the recipients) until your IT staff cleared up the blacklisting issue. This phenomenon is called “backscatter blacklisting”.

Know more: Free Encrypted Email

2. I copied (cc’d or bcc’d) myself and got the copy – so I know my message was delivered to all recipients.

This is a false assumption.

Why? Receipt of internal email within the organization does not have any bearing as to whether or not the email got to the Internet – and certainly does not prove delivery.

Here is a technical explanation of why that is the case. In most cases, if the sender and recipient have the same email domain (the domain being “”), the email will never need to transmit from your mail server to the Internet to reach the recipient. The email will travel from your computer to your mail server, and then, if your mail server sees the recipient domain as its own, it will look up the recipient in its own local directory, and put the email into that recipient folder (mailbox) locally on the mail server. The email will not need to be transmitted to the Internet to reach the recipient.

In the case where you copy yourself (or staff) on the message going to an external party, the message to your (and your staff) will remain on your mail server, and the message copy for the external party will transmit to the Internet. Whether it is delivered will be dependent on a number of Internet delivery variables, but delivery success is independent of whether or not you (or staff) received their copy.

In next week’s brief, we will introduce and debunk several other common misconceptions about proving email delivery.

RMail provides an email encryption feature that is easy for both senders and recipients to use. Learn more about RMail. RMail is an RPost service.