19

I received an "Undelivered Mail Returned to Sender" email, which is quite suspicious.

The message is displayed in Thunderbird like this:

From: someRandomStuff my.name@mail.provider
Date: 24.08.20, 21:05
To: a list of very random looking email addresses, probably machine generated

Is this simply a case of using some email address in the reply-to field, or is there something worse going on?

Dohn Joe
  • 561
  • 4
  • 8

2 Answers2

24

In addition to @SteffenUllrich, you might also want to double check the headers of the attached mail.

In particular, pay a lot of attention to the Received: from header (well.. the header is just Received...).

Two circumstances (asssume mx.example.org is the server who sends the return):

  1. You don't find your own MX on the stack. ✔ Case closed, someone is (failing at) spoofing your email

  2. You do find your own MX somewhere on the stack. Now check:

    1. If your server is the first entry after mx.example.org…

      You must investigate further. Your account might really have been pwned (because of a leaked password) to be used for spam. You may want to check your password for leakage at haveibeenpwned.com and the server logs for suspicious activity.

      Another interpretation is that the header, which is just a plaintext header, was forged. This would mean that there is no attempt to deliver mail at someone@example.org but instead someone else is trying to deceive you into thinking you sent an undeliverable mail. It is unlikely, but without checking the contents of the attached email for malware, it's just hypotetical. Also, don't forget that the foreign mail server could be poorly configured, worse than not just checking for SPF/DKIM.

    2. If your server is not the first entry after mx.example.org…

      ⚠ This means that the email claims to have bounced back and forth. It is unlikely, especially for how SPF works. Unless some strict corporate routing configuration for firewalled stations, emails travel non-stop from the origin ISP to the destination ISP 99.9% of cases. In that case, the header was very likely forged to give more credibility to the email, deceiving old antispam filter ("hi Mr. mail server, I have to deliver a mail to you that was given to me by the intended sender"). I'd still trash it, but maybe you would take a look, low priority, at the logs for message id. Just as a triple-check.

      You can somewhat reduce the problem of such misuse by having strict SPF policies (and better also DKIM and DMARC) but this does not help much if the initial mail server will not check such policies or not block the mail based on the policies.

      This was my case, and apparently the server never enforced those policies on their side to discard that mail allegedly coming from myself. Case closed.

usr-local-ΕΨΗΕΛΩΝ
  • 5,310
  • 2
  • 17
  • 35
4

Somebody is using your email address as the claimed but spoofed sender of a mail. This is not about Reply-To or From in the mail header, but happens if the sender in the SMTP dialog is spoofed (From can still be spoofed additionally to this). The mail bounced back to you as the claimed sender probably because the recipient could not be found, but maybe also because it was considered spam or malicious.

Given that the list of recipients seem to be randomly generated, your email address was likely used only for spamming. You can somewhat reduce the problem of such misuse by having strict SPF policies (and better also DKIM and DMARC) but this does not help much if the initial mail server will not check such policies or not block the mail based on the policies.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Note further that the mail server the "undeliverable" notice came "back" from is severely misconfigured and is usable as a vector for spam and malware delivery. It should have rejected the mail at SMTP acceptance time, leaving the spammer responsible for notifying themselves that it couldn't be delivered, rather than accepting it then sending a bounce message to an address obtained from an untrusted source. – R.. GitHub STOP HELPING ICE Aug 31 '20 at 17:22
  • 1
    @R..GitHubSTOPHELPINGICE: While this would ideally be the case it is not always possible. Mail delivery is not done between two servers only. The mail server responsible for a domain might not know which users are actually available or which mails are acceptable but only forwards the mail to some inner server which then might reject the mail. Since the outer server has already accepted the mail it must now generate a delivery status notification with the error - all this is actually standardized. – Steffen Ullrich Aug 31 '20 at 18:50
  • @R..GitHubSTOPHELPINGICE if `mail.provider` doesn't have a SPF record with `-all` disqualifying the sender IP, the mail server that sent the undelivery has no way to know if it was not a legit sending ip. It is **very** desirable for email to be rejected inline, rather than sending a bounce, but it's not always possible. Plus, sending a bounce doesn't mean it is _is usable as a vector for spam and malware delivery_. – Ángel Aug 31 '20 at 21:42
  • @Ángel: SPF is not relevant; this was the case long before SPF existed. You can only send undeliverable messages if the full chain of possession up to you is authenticated, i.e. if you're the sender's outgoing mail system. If you're the primary or backup MX for the recipient you MUST be able to either commit to delivery or reject the mail during the SMTP session. Back in the 80s and early 90s what you're saying was done, but it's completely unreasonable in a post-spam world and it WILL be used as a vector for abuse. – R.. GitHub STOP HELPING ICE Aug 31 '20 at 22:41
  • @R..GitHubSTOPHELPINGICE, reference for your MUSTs, please? AFAIK rfc still stipulate that old behavior (which is undesirable for generating backscatter, and thus not recommended. It can be used for abuse by filling someone's mailbox, but I wouldn't consider it a vector for spam or malware delivery). You can blackhole bouncing. But then legitimate senders are not notified of errors delivering their mail. And moreover, you should not spend too much time analysing the content of `DATA`. Sometimes you have no good option. – Ángel Aug 31 '20 at 23:01
  • @Ángel: It's a trivial vector for malware delivery, phishing, etc. You make it look like either something your victim sent was undeliverable, or like someone was using their account, and include a link that entices them to open it. – R.. GitHub STOP HELPING ICE Aug 31 '20 at 23:18
  • @R..GitHubSTOPHELPINGICE that only works _if_ the bounce includes the complete message, not just the headers. Plus, what I see are the MUA showing the raw email contents, so a naive user wouldn't be able to open an attachment carried along a faithful undelivery message. I wonder if we are talking about the same schema, though. – Ángel Aug 31 '20 at 23:26