The verification email is a reflection primitive

Type an address into Pangram’s sign-up form and the page fires one request:

curl --request POST --data '{"email": "[email protected]"}' https://www.pangram.com/api/validate-email

Shortly after, with no further action, that address receives an unrelated email. It comes from “Winwin Insights” [email protected], subject “Fact of the day: Magnetic,” a base64-encoded HTML body whose only content is a hidden div (position: absolute; left: -9999px; display: none) holding a few paragraphs about magnetic domains in ferromagnetic materials.

The email-validation step is implemented by mailing the address.

That sender behaves like a spam operation because it is one. It rotates through a list of sender domains: apiaryapiaries.com, bonfirebeat.com, classmerge.com, sifgoldenshine.com and a couple dozen more in the author’s non-exhaustive list. When a receiving server rejects a message it retries immediately from a different host. The author’s Postfix log shows three attempts in eight seconds: mta2.icicleglimmerfrost.com rejected by spam.spamrats.com, mailc.plowdairy.com rejected by b.barracudacentral.org, then servidor.classmerge.com accepted and the message delivered. Several of the sending IPs are already listed on DNSBLs.

The request shown posts one field, the address, and that address received the mail. An endpoint that turns a posted address into a message sent to it reads as a reflection primitive, with Pangram’s form triggering the send and the spam operator’s infrastructure carrying it.

As a way to check an address it cannot work. If the message lands, you have “validated” the address by spamming its owner. If the receiver does content filtering, the message gets rejected and validation fails for a perfectly deliverable address. The base64 encoding and the off-screen magnetic-domains text are the standard moves for slipping past filters, which says the operator is optimizing for delivery, not producing any signal a caller could read back.

The author guesses this is some SaaS that “validates” email this way, or an LLM agent that wandered off its task. Pangram’s actual transactional mail goes through Mailgun; this spam-send does nothing a verification link would not do better.

If you run a sign-up flow, don’t buy address validation that proves deliverability by delivering something. Send your own verification link through your transactional provider and treat the click as the signal. And if you expose any endpoint that triggers outbound mail to a user-supplied address, assume someone will use it to mail addresses their owners never handed you: require authentication, rate-limit per source, and scope the triggered mail to addresses tied to the authenticated account.