Most people these days filter while the SMTP session is still open. Reject while session is open and the actual sender gets the rejection.
Forged reply-to only works when the session is closed and you accept the email then decide to bounce it.
this post was submitted on 26 Apr 2025
43 points (100.0% liked)
Cybersecurity
0 readers
15 users here now
An umbrella community for all things cybersecurity / infosec. News, research, questions, are all welcome!
Rules
Community Rules
- Be kind
- Limit promotional activities
- Non-cybersecurity posts should be redirected to other communities within infosec.pub.
founded 2 years ago
MODERATORS
@kalpol@lemm.ee No idea what you are saying here. But, you can argue with Google: https://support.google.com/mail/thread/209018675/my-sent-email-box-is-filling-up-with-bounce-emails-and-emails-i-did-not-send-my-inbox-is-fine?hl=en
I'm saying this is the fault of people running badly configured mail servers. If you filter and bounce during the SMTP session instead of afterward, you won't be emailing bounces to the forged reply-to address. Same as having an open relay. Just fix your junk if you run a mail server.
I haven't looked into email in a while, but I'm pretty sure this is like saying TCP is insecure. Like yeah, if you communicate using plaintext over TCP you are vulnerable but most out of the box solutions nowadays don't even function that way. You'd have to go write your own application that communicates using plaintext over TCP.
In the same vein, the boxes out there that just run SMTP without any security would be the same way, but most boxes won't be susceptible to this attack because very few people are running just SMTP.
Disclaimer: I have not read up on SMTP in awhile but iirc, SMTP works with very little verification and is very susceptible to a lot of different attacks by itself.
@ExperimentalGuy@programming.dev This doesn't involve security. This is just about a protocol that says a server must let you know, via one email for each rejection, that an email with your from address couldn't be delivered, regardless of whether you sent it.
It's a procedural problem.
If a spammer sends 5 million emails with your email address in the FROM: then you can expect hundreds of thousands of messages from your email provider telling you that it couldn't deliver an email, for whatever reason.
Here. Let Google explain it: https://support.google.com/mail/thread/209018675/my-sent-email-box-is-filling-up-with-bounce-emails-and-emails-i-did-not-send-my-inbox-is-fine?hl=en
SPF
DKIM
Dmarc
You might want to learn about those as well.
@ikidd@lemmy.world People are not reading. You are not reading.
SPF, DKIM and DMARC are not relevant. Those are instructions to the receiving servers which are not the ones sending the bounces. The receiving server is telling the sending server, based on these DNS records, that it will not accept the message. It refuses them. Period. No bounce message.
The sending server then, as a courtesy, lets the sender know, solely based on the FROM: address, that the email could not be delivered, as one by one messages.
There are no DNS records or configurations that control this. The SMTP server follows the protocol which is to inform the FROM: address, as a courtesy, that the email was not accepted. It is the sender. It does not look at SPF, DMARC, and DKIM rules. That is only what the destination server uses.
The point is that if an SMTP server is respecting RFC7208 then you don't get those bounces if you have the records. Which is most SMTP servers now.
My hotmail inbox says that Miocrosoft must then not be a member of the "most" group.
Maybe Hotmail, I couldn't say about freemail domains, but I get dmarc reports for recipients on Office 365 hosted domains all the time and have for years. They were one of the earliest adopters, since I've had a dmarc policy for my domains for over a decade.
DMARC reports are sent by the receiving server, which is not the server sending the bounces. They are reports sent to the domain owner. SPF, DKIM and DMARC are only meant as tools to protect the domain owner and indicate when an email should not be accepted.
These bounces are coming from the sending server whose email attempt got rejected by the receiving server. They are NDRs which are not covered by SPF, DKIM, or DMARC.
The sending server is informing the FROM: address, as a courtesy, that the email could not be delivered, even when the sending server knows the FROM is likely fraudulent. This has nothing to do with SPF, DMARC or DKIM and is a different protocol.
Argue with Google, not me: https://support.google.com/mail/thread/209018675/my-sent-email-box-is-filling-up-with-bounce-emails-and-emails-i-did-not-send-my-inbox-is-fine?hl=en
Is the recipient server drops or quarantines spam instead of rejecting it (which is standard best practice), the sending server will never know, and won't send a message back to the sender.
DMARC has only 3 options. Ignore, reject or quarantine. There is no "drop" instead of "reject". And anything other than an "ignore" will cause a reject from the receiving server back to the sending server who will then inform the FROM address that the email was not delivered.
There's a bunch of things wrong in this post. Mainly, you should take a look at DNS SPF records.
That's why it bounces!
An unauthorized sender IP should have their messages dropped, not bounced.
Yes, but then what? Your email provider will kindly let you know, as a courtesy, that the email you sent could not be delivered. Normally, you want this notification. Unfortunately, hotmail, for example, for one, does not determine whether you really sent the email or not. That the FROM: address has you, It will inform you anyway that the email was not delivered. There are no DNS records to stop this.
Nope, they look up the domain dmarc record for the sending domain and add all the dropped records to a aggregated abuse report which is sent as one email to your postmaster.
If the email is not accepted by the receiving imap or pop3 server, it sometimes follows the DMARC instructions for reporting. The report goes to the domain owner of the sending domain. This is done by the receiving server. SPF, DKIM, and DMARC are instructions to the RECEIVING email server, not to the sending email server.
The bounce I'm talking about is from your SMTP server that is following the protocol to let you know, as a courtesy, that your email could not be delivered. And that protocol simply says, in the absence of anything else saying otherwise, tell the FROM: address that their message did not get delivered, even if there is strong evidence that the FROM: address is a fraud.
You keep saying we don't read or we don't understand, but as an email admin at a large company, let me tell you that actually you are wrong.
The sending server doesn't even know whether the spam mail was delivered or dropped by the receiving end.
It only knows in case the mail was rejected.
I'm very sure that, by default, at least postfix will send bounces only to local senders. So unless the spammers use your SMTP server to send spam, you shouldn't get any bounces. If they do, you have different problems.
Tell that to hotmail because they keep sending it. And be sure to update Google too because they don't know as much as you either. https://support.google.com/mail/thread/209018675/my-sent-email-box-is-filling-up-with-bounce-emails-and-emails-i-did-not-send-my-inbox-is-fine?hl=en
My mail server has no knowledge of the mails the spammer sent, what are you talking about? This is no open relay.
@Jerry@hear-me.social
There is 2 mechanisms against this.
- SPF
- Signature with DKIM
Your provider should check these.
Many providers don't accept email if one is missing or wrong, or flag theses emails as spam.
@lautreg SPF and DKIM are only used by the destination IMAP or POP3 servers to see what to do when they receive the email. In this case they reject it.
The delivery failure message is coming from the sending server as a courtesy message to the sender to let them know their email was not delivered. The protocol is to tell the FROM: address that the email could not be delivered. The SMTP, sending server, doesn't look at SPF, DKIM or DMARC or any DNS records or any other configuration related to it. It simply tells you the millions of emails sent with your FROM: address could not be delivered, one by one.
People keep bringing up SPF, DKIM, and DMARC, but it's not relevant to this problem.
@Jerry@hear-me.social
Oh yes.
I can't check, but I think there is setting to refuse connexion with the sender server if SPF doesn't mach.
Like the policy in the DMARC?
Or, in spamd/spamassassin, to just drop the incoming email in these case?
(I'm on phone, I may write more wrongly than usual)
@Jerry@hear-me.social when smtp was invented, the internet was a friendly, academic space, not a commercial molloch. The pain smtp is causing the last 30 years, isn't enough, to switch over to encryted and signed E-mail
The protocol was designed when there were practically no people on the net, compared to present day. In the beginning it was even customary to go by your own name.
In the beginning it was even customary to go by your own name.
That’s just crazy talk.
You want DMARC to protect the header From. This will protect you from backscatter due to out of office replies etc. Bounces go to the envelope from and are due to rejected mails.
TL;DR Implement SPF to not get bounces and implement DMARC to not get backscatter.
SPF can't be set up to stop bounces. It just indicates which servers are authorized to send email for the sending domain. It has nothing to do with the FROM: address. It's only there to protect the owner of the domain from where the email is sent. It does not care about you.
DMARC tells the receiving email server what to do if SPF and DKIM fail and often the instructions are to do nothing.
If the receiving server ends up refusing the email because it fails SPF and/or DKIM and DMARC says to reject, the SMTP server, not the receiving server, sends the bounce to the FROM: address to tell the person their email could not be delivered.
In summary, SPF and DKIM are about whether the email should be delivered. It says nothing about informing the sender that their email was not delivered. That's a courtesy provided by your email provider.
Yes, however RFC7208 says not to send NDR when sender authentication fails (=when SPF/DMARC is correctly set up it will fail) So you will get massively less backscatter. There will still be some providers sending NDRs however not the big ones, they will instead inform you via DMARC reporting which is easier to ignore.
Generating non-delivery notifications to forged identities that have
failed the authorization check often constitutes backscatter, i.e.,
nuisance rejection notices that are not actionable. Operators are
strongly advised to avoid such practices
It's still incumbent on the receiver to implement and follow DMARC and SPF rules. Email is, what, 44 years old, if you include RFC 822. SPF was introduced a mere 20 years ago, and DMARC is only 12 years old; Google started enforcing it only 10 years ago. There's an entire sea of email server out there whose admins have not bothered to set up SPF, much less DMARC.
There's a huge gap between "should" and "do."
Apparently, hotmail hasn't read the memo because they've been sending them for me today
Ah yes. But you can just reject NDR messages with "550 5.7.509: Access denied, sending domain example.net does not pass DMARC verification and has a DMARC policy of reject" now.
emails
If you can't spell the word right, I doubt your expertise on it.
Look up "Joe job" in this context. It's what we've called it for decades.