Did any site implement incoming emails to signup@domain.com which then sends you a timebound signup form? No spam filtering drama.
Kiwifarms did something like that, where you have to send an email to confirm your signup.
Don't verify email addresses by sending spam to them
61–67 of 67 posts
Re: Don't verify email addresses by sending spam to them
#62Hey! Founder of Pangram here. We use Zerobounce and CustomerIO for email validation. I had no idea this was happening. Not entirely sure which one this is coming from, but this is not intentional on our part. Will dig deeper and eliminate the part of the stack that is sending spam — definitely not good that this is happening.
[deleted]
Re: Don't verify email addresses by sending spam to them
#63Hey! Founder of Pangram here. We use Zerobounce and CustomerIO for email validation. I had no idea this was happening. Not entirely sure which one this is coming from, but this is not intentional on our part. Will dig deeper and eliminate the part of the stack that is sending spam — definitely not good that this is happening.
Follow-up: our vendors have told us that they do not send any emails as part of the validation process. Either somebody is lying, or there's something even weirder going on. We still have more tests to run to isolate which software package it could be.
Re: Don't verify email addresses by sending spam to them
#64Earlier quoted context omitted.
email can be read by any server in the chain between the sender & recipient. It's not secure. PGP doesn't fully fix this, it still leaks message content (subject) and metadata. So does S/MIME. That doesn't mean attachments are leaked, but it does mean email isn't compliant with any of the standards which require communicating securely.
Right. I'm saying this state of affairs is unacceptable for the dominant digital messaging system in 2026.
I agree. The problem is that anything which solves this won't be compatible with email, since these issues are inherent to the protocol. Fixing email isn't possible, so the solution has to be replacing it. Unfortunately that's very difficult.
Re: Don't verify email addresses by sending spam to them
#65Hey! Founder of Pangram here. We use Zerobounce and CustomerIO for email validation. I had no idea this was happening. Not entirely sure which one this is coming from, but this is not intentional on our part. Will dig deeper and eliminate the part of the stack that is sending spam — definitely not good that this is happening.
Follow-up: our vendors have told us that they do not send any emails as part of the validation process. Either somebody is lying, or there's something even weirder going on. We still have more tests to run to isolate which software package it could be.
Update: this is actually ZeroBounce’s Verify+ feature which we figured out after some escalation. It’s now disabled!
Re: Don't verify email addresses by sending spam to them
#66Earlier quoted context omitted.
Right. I'm saying this state of affairs is unacceptable for the dominant digital messaging system in 2026.
I agree. The problem is that anything which solves this won't be compatible with email, since these issues are inherent to the protocol. Fixing email isn't possible, so the solution has to be replacing it. Unfortunately that's very difficult.
It would be interesting if there was a DNS record of some kind to announce a PKI registry for a particular domain's email addresses. This would allow for some kind of decentralized discovery of suitable public keys for individual addressees.
But, a potential sender with important messages still needs do some pre-flight email verification over this path, e.g. sending a verification code encrypted the same way, to validate that the intended user can read it and send it back via another authenticated channel. This ensures that the sender-specific user identity actually possesses control of that email address and the discovered private key. It also reduces the impact of a malicious email provider to only denial-of-service rather than content interception.
So, is that discovery protocol worth it, versus just having an opt-in setting where the user supplies their desired public key and email address in the same form?
Re: Don't verify email addresses by sending spam to them
#67Earlier quoted context omitted.
You didn't answer this question: > Who can read it today?
Well, the email providers. And that could easily include Google without you even realising. It's true that email isn't quite as insecure as it used to be (it was once compared to shouting your message at someone and expecting them to shout it in the right direction until it reached the intended recipient), but there are still many things missing compared to other forms of direct messaging, and there's good reason why…
How is that different from your browser and the bank website being able to read the same PDF transmitted through the website?