This is for commentary, articles and discussion of anything across Jared's tech network. Since the network has different things, it can all still fit here on the blog.
One of the lessons we regularly repeat on The Security Box and Throwback Saturday Night is simple: do not trust the name displayed by your email program. Look at the sender’s complete email address.
A suspicious message I received today provides a good example of why that advice matters.
The message appeared in my inbox with the following sender information:
Facturacion.jaredrimer.net <>
The display name attempted to associate the message with my own domain. The actual email address, however, belonged to the completely unrelated domain 91kuaibao.com.
Anyone who looked only at the prominently displayed name might have assumed that the message came from an accounting or billing department connected with jaredrimer.net. Reading the entire sender line immediately exposed the mismatch.
What the message said
The email was written in Spanish and addressed me by name. It said:
Buen dia, jared.
Soy el nuevo contador.
Actualmente, revisé algunos documentos de nuestra empresa y descubrí que nuestra empresa tiene algunos pagos atrasados que no se han enviado a su empresa. confirme la factura y los datos bancarios para que podamos continuar con los pagos hoy
Espero tus comentarios antes.
Saludos Cordiales
Carlos Augusto
+56 9 6646 3295
Translated into English, the sender claimed to be a new accountant who had discovered overdue payments that had not been sent to my company. The message asked me to confirm an invoice and banking information so the payments could supposedly continue that day.
I do not have an accountant named Carlos Augusto, I was not expecting a payment from this sender, and the actual email address had no connection to me or my business.
The suspicious attachment
The message included the following attachment:
Confirmacion_de_Pago_Pendiente.pdf.uue
The filename translates roughly to “Pending Payment Confirmation.” Someone scanning the name quickly might notice “.pdf” and assume that the attachment is an ordinary PDF document.
It is not a normal PDF attachment. The final extension is “.uue.”
UUE refers to UUEncode, an old method of converting binary files into text so they could be transmitted through systems that were not designed to handle binary attachments. It was useful during the early history of email, before modern MIME attachments became standard.
UUEncode is not automatically malicious. However, there is very little reason for an ordinary company to send a modern invoice or payment confirmation this way today. Receiving an unexpected banking request with a “.pdf.uue” attachment is extremely suspicious.
The double extension is also important. A recipient might stop reading when encountering “.pdf” and overlook the actual extension at the end of the filename.
What the email headers revealed
The message headers showed that this was not a technical spoof of jaredrimer.net. The message really was sent using the domain 91kuaibao.com.
The return address and envelope sender were both . The sending server identified itself as 91kuaibao.com, and the message was transmitted from the IP address 192.255.136.75.
The message also contained a valid DKIM signature for 91kuaibao.com, and the receiving server reported that SPF passed.
That does not make the email legitimate.
SPF and DKIM can establish that a server was authorized to send email for a particular domain. In this case, they helped establish that the message came from infrastructure authorized to send mail for 91kuaibao.com.
They did not establish that the sender had any relationship with me, that the payment claim was real, or that the attachment was safe.
The sender was not successfully authenticating as jaredrimer.net. Instead, the deception occurred in the display name, where the attacker entered “Facturacion.jaredrimer.net” while sending from an unrelated address.
The spam filter missed it
Another important part of this example is that the receiving mail system did not classify the message as spam.
The message received a SpamAssassin score of 2.0, below the configured spam threshold of 5.0. The headers therefore contained the result:
X-Spam-Flag: NO
The analysis did identify some concerning characteristics. It reported HTML-only message content, an unusually handled PDF attachment, and a reference associated with an abuse blocklist. Those findings were not enough to push the message over the system’s spam threshold.
This is a useful reminder that spam filtering is only one layer of protection. A message reaching the inbox does not mean that it has been examined and declared safe.
The warning signs
This message contained several warning signs:
The display name referenced my own domain, but the actual sender address did not.
The sender claimed to be a new accountant whom I did not know.
The message referred vaguely to overdue payments without identifying an invoice, contract, company, or previous transaction.
It requested confirmation of banking information.
It attempted to create urgency by saying the payments could continue that day.
It included an unexpected attachment with the unusual extension “.pdf.uue.”
The signature provided a name and telephone number but did not identify a company.
No single warning sign is always conclusive. Taken together, however, these signs make the message highly suspicious.
Why the complete email address matters
Email display names are not reliable proof of identity. A sender can often enter almost anything into that field.
A message can display the name of a bank, delivery company, employer, government agency, friend, or even the recipient’s own domain while originating from an unrelated address.
That is why we continue telling listeners to inspect the complete email address.
In this example, the display name said:
Facturacion.jaredrimer.net
The email address said:
The second line is the one that mattered.
What recipients should do
Do not open an unexpected attachment simply because the filename contains “.pdf.” Read the entire filename, including the final extension.
Do not send or confirm banking information in response to an unsolicited email. Contact the supposed sender through a telephone number, website, or email address that you already know to be legitimate.
Do not rely exclusively on the display name, SPF, DKIM, or the absence of a spam warning. Each of those can provide useful information, but none of them proves that the message’s claims are true.
In this case, checking the actual sender address was enough to expose the problem before anyone had to find out what was hidden inside the attachment.
Conclusion
This message provides a real-world demonstration of a basic but important security practice.
Read the complete sender address.
The display name tried to connect the message with my domain. The actual address showed that it came from somewhere else entirely. The vague payment story, request for banking details, artificial urgency, and unusual UUE attachment supplied the remaining evidence.
An email does not become trustworthy because it reaches the inbox, addresses you by name, or passes authentication for the domain that sent it.
Stop, examine the sender, read the entire filename, and verify financial requests independently before opening attachments or providing information.
When the Display Name Lies: A Suspicious Payment Email Lands in My Inbox
One of the lessons we regularly repeat on The Security Box and Throwback Saturday Night is simple: do not trust the name displayed by your email program. Look at the sender’s complete email address.
A suspicious message I received today provides a good example of why that advice matters.
The message appeared in my inbox with the following sender information:
Facturacion.jaredrimer.net <>
The display name attempted to associate the message with my own domain. The actual email address, however, belonged to the completely unrelated domain 91kuaibao.com.
Anyone who looked only at the prominently displayed name might have assumed that the message came from an accounting or billing department connected with jaredrimer.net. Reading the entire sender line immediately exposed the mismatch.
What the message said
The email was written in Spanish and addressed me by name. It said:
Soy el nuevo contador.
Actualmente, revisé algunos documentos de nuestra empresa y descubrí que nuestra empresa tiene algunos pagos atrasados que no se han enviado a su empresa. confirme la factura y los datos bancarios para que podamos continuar con los pagos hoy
Espero tus comentarios antes.
Saludos Cordiales
Carlos Augusto
+56 9 6646 3295
Translated into English, the sender claimed to be a new accountant who had discovered overdue payments that had not been sent to my company. The message asked me to confirm an invoice and banking information so the payments could supposedly continue that day.
I do not have an accountant named Carlos Augusto, I was not expecting a payment from this sender, and the actual email address had no connection to me or my business.
The suspicious attachment
The message included the following attachment:
The filename translates roughly to “Pending Payment Confirmation.” Someone scanning the name quickly might notice “.pdf” and assume that the attachment is an ordinary PDF document.
It is not a normal PDF attachment. The final extension is “.uue.”
UUE refers to UUEncode, an old method of converting binary files into text so they could be transmitted through systems that were not designed to handle binary attachments. It was useful during the early history of email, before modern MIME attachments became standard.
UUEncode is not automatically malicious. However, there is very little reason for an ordinary company to send a modern invoice or payment confirmation this way today. Receiving an unexpected banking request with a “.pdf.uue” attachment is extremely suspicious.
The double extension is also important. A recipient might stop reading when encountering “.pdf” and overlook the actual extension at the end of the filename.
What the email headers revealed
The message headers showed that this was not a technical spoof of jaredrimer.net. The message really was sent using the domain 91kuaibao.com.
The return address and envelope sender were both . The sending server identified itself as 91kuaibao.com, and the message was transmitted from the IP address 192.255.136.75.
The message also contained a valid DKIM signature for 91kuaibao.com, and the receiving server reported that SPF passed.
That does not make the email legitimate.
SPF and DKIM can establish that a server was authorized to send email for a particular domain. In this case, they helped establish that the message came from infrastructure authorized to send mail for 91kuaibao.com.
They did not establish that the sender had any relationship with me, that the payment claim was real, or that the attachment was safe.
The sender was not successfully authenticating as jaredrimer.net. Instead, the deception occurred in the display name, where the attacker entered “Facturacion.jaredrimer.net” while sending from an unrelated address.
The spam filter missed it
Another important part of this example is that the receiving mail system did not classify the message as spam.
The message received a SpamAssassin score of 2.0, below the configured spam threshold of 5.0. The headers therefore contained the result:
The analysis did identify some concerning characteristics. It reported HTML-only message content, an unusually handled PDF attachment, and a reference associated with an abuse blocklist. Those findings were not enough to push the message over the system’s spam threshold.
This is a useful reminder that spam filtering is only one layer of protection. A message reaching the inbox does not mean that it has been examined and declared safe.
The warning signs
This message contained several warning signs:
No single warning sign is always conclusive. Taken together, however, these signs make the message highly suspicious.
Why the complete email address matters
Email display names are not reliable proof of identity. A sender can often enter almost anything into that field.
A message can display the name of a bank, delivery company, employer, government agency, friend, or even the recipient’s own domain while originating from an unrelated address.
That is why we continue telling listeners to inspect the complete email address.
In this example, the display name said:
The email address said:
The second line is the one that mattered.
What recipients should do
Do not open an unexpected attachment simply because the filename contains “.pdf.” Read the entire filename, including the final extension.
Do not send or confirm banking information in response to an unsolicited email. Contact the supposed sender through a telephone number, website, or email address that you already know to be legitimate.
Do not rely exclusively on the display name, SPF, DKIM, or the absence of a spam warning. Each of those can provide useful information, but none of them proves that the message’s claims are true.
In this case, checking the actual sender address was enough to expose the problem before anyone had to find out what was hidden inside the attachment.
Conclusion
This message provides a real-world demonstration of a basic but important security practice.
Read the complete sender address.
The display name tried to connect the message with my domain. The actual address showed that it came from somewhere else entirely. The vague payment story, request for banking details, artificial urgency, and unusual UUE attachment supplied the remaining evidence.
An email does not become trustworthy because it reaches the inbox, addresses you by name, or passes authentication for the domain that sent it.
Stop, examine the sender, read the entire filename, and verify financial requests independently before opening attachments or providing information.
Share this:
Like this:
Related
Discover more from Jared's Technology podcast network
Subscribe to get the latest posts sent to your email.
Published in musings and security news and commentary