"Undelivered Mail" I never sent (after registration on website)

Question

I created an online account and received the usual welcome email. In addition, however, an "Undelivered Mail Returned to Sender" email appeared in my inbox one second later. I am the supposed sender, and the website I registered on the recipient. The email which could not be delivered contains (in plain text as well as in a .csv attachment) all the information I had entered upon registration. The website itself seems trustworthy/legitimate.

Since I definitely did not send an email (and do not see an email in my outbox or sent folder), I wonder how this is possible and whether this poses a security risk.

I found a related question here on this site ( i-received-an-undelivered-mail-is-my-email-address-used-maliciously), but I can't quite connect the dots.

• It seems unlikely to me that my email was hacked or maliciously used at exactly that point of time. The password I used on the website was randomly generated and is almost surely unique among all my passwords.
• If the header was forged and someone was trying to deceive me that I had sent an email, I'd wonder why the email and attachments contained the information I entered upon account creation. If that was a third party, would this mean the website could be compromised? Again, the timing make me wonder if this is realistic.
• If it was a poorly configured foreign server, why would it appear as if I had tried to send an email with that specific content. The information, as far as I understand, should have been submitted/sent through the registration form. Why send another email with the same information? Why would it appear as if the email was sent from my email address?

I would appreciate if someone could shed some more light on this. Please find part of the email header (with my and the website's info anonymized) below. Please excuse the use of an image, but otherwise this post was classified as spam.

I also found failed-to-send-emails-that-i-never-sent, but the context is quite different to mine. In my case, the undeliverable email seems to be specifically related the the registration on the website.

Answer 1

It looks like the web service in question has configured their system to forward the welcome emails to an internal address on their end, but misconfigured their system such that the From: line is the customer's address rather than some internal address that they control. Intentional or not, they also fail to consider DMARC, so customers wind up with sketchy-looking emails like this about the website trying to email on their behalf from an unauthorized host.

You could help the service out by letting them know about the configuration issue, but ultimately things are working as they ought to as far as your email setup is concerned, so you are safe to just brush this off without consequence too. There does not appear to be any malicious intent, but the way the emails are sent with whatever PII it had is not exactly commendable.

As for why they would do this, I'm imagining that they have a weirdly tacked-together process for taking information from their registration form and delivering it to another service via SMTP since there was a CSV attached. As long as the receiving address was controlled by them, my best guess is that they're handling registrations in a frustratingly unsafe, roundabout, and kludgy way for purposes of logging, debugging, "backups," or—shudder to think—processing.

I'm also going to speculate that their Fiverr dev(s) received little oversight when stringing this together. In reality, though, this could just be that some developer had set this up as a meantime debugging measure and failed to disable it in production before anyone noticed. I'd email them.

Answer 2

It used to be a fairly common practice to forge the sender on some internal emails so that the admin can easily add your address to their address book.

such practice runs foul of DKIM, VERP, and SPF protections so the recipient must whitelist the web server if they have any forgery prevention measures on their mailbox server.

In this example it gets rejected by gmail.

To fix this __WEBSITE_EMAIL__ needs to whitelist their own server in their G-suite account or shift their MX and mailbox (or signup conversion email account) to a different provider and whitelist it there.

The easiest fix is probably to stop using SMTP for this path and instead set up a POP3 or IMAP account on __DOMAIN_OF_WEBSITE__ and have their gmail account pull the emails instead of pushing them using SMTP.

Answer 3

One very specific, but possibly common reason is this: The mail is sent by some software, like the popular Wordpress Contact Form 7 plugin, which allows to configure to and from fields in a GUI, but doesn't have the same comfort for the "reply-to" field. Now someone who might not even know what the "reply-to" field is configures the mails such that hitting reply will send an e-mail to the person who filled out the form. Then if there is a problem with the "to" adress, the mails will bounce to the wrong adress.

If you do this correctly with the "reply-to" field it can be a fairly practical workflow even today: You might want to download aggregate form-data from somewhere periodically or handle the data automatically, but this still notifies you when there is new data (especially in the case of infrequently used forms) and in many cases there is a subset of form entries which you might want to answer by mail (usually because there is a free text comment field in the form) and that way you can do so very easily.