不要通过发送垃圾邮件来验证电子邮件地址。
Don't verify email addresses by sending spam to them

原始链接: https://milek7.pl/mailverifyspam/

作者指出了一种在电子邮件验证中既误导又具有侵入性的趋势:利用垃圾邮件来验证地址。一些服务(例如“Pangram”)并没有使用标准的验证链接,而是在用户于注册表单中输入地址后,立即触发未经请求的批量群发邮件。 这种方法存在明显的缺陷。首先,这构成了垃圾邮件行为,损害了发送方的声誉。其次,这种方式并不可靠:如果邮件被接收,发送方仅仅是通过发送垃圾邮件验证了该地址;如果邮件被过滤器或 DNS 黑名单拦截(作者观察到这种情况经常发生),则“验证”会完全失败。 作者对这一策略所投入的精力表示不解,并指出发送方会积极轮换大量域名,并在被封锁时尝试从不同的服务器重新投递。这种做法似乎是试图绕过标准验证流程的错误尝试,其背后可能由设计拙劣的第三方“验证”SaaS 或自动代理程序所驱动。最终,作者认为这种做法适得其反且荒谬可笑,因为它除了骚扰收件人和阻塞邮件服务器之外,没有任何实际的正当用途。

最近的一场 Hacker News 讨论调查了有关 Pangram 服务向其验证 API 输入的地址发送未经请求的神秘邮件的报告。用户发现,这些邮件通常包含隐藏的无意义文本(例如关于磁性的维基百科条目)以及不可见的追踪元素。 社区成员认为这种行为源于第三方电子邮件验证工具(如 ZeroBounce),这些工具可能会通过侵入性手段“预热”或测试电子邮件地址,以绕过垃圾邮件过滤器并识别蜜罐。尽管一些评论者怀疑这是恶意的数据收集或泄露,但 Pangram 的创始人否认了有意发送垃圾邮件,将其归咎于其技术栈中集成的外部服务,并承诺会进一步调查。 这场讨论引发了关于现代电子邮件现状的更广泛辩论。用户批评该行业过度依赖侵入式追踪像素,以及强制用户访问不安全网站而非发送安全附件的“无纸化”系统。许多参与者对电子邮件验证演变为损害用户隐私的“测试”策略表示不满,并呼吁建立更好、标准化的端到端加密来取代这些有问题的验证工作流。
相关文章

原文
Don't verify email addresses by sending spam to them

23.06.2026

Much have been said about futility of trying to validate email addresses. Generally accepted advice is that you should just send verification link and don’t care about trying to validate it beforehand.

But what if you were really hell-bent on having validation step, and at the same time follow the advice? Apparently some people decided they could to it by… sending spam.

Take this Pangram sign-up form. Filling email field here will perform this request:

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

And soon enough, without doing anything else, you will get an mysterious email. Whaaa…?

Date: Tue, 23 Jun 2026 15:29:10 +0000
From: "Winwin Insights" <[email protected]>
To: <[email protected]>
Reply-To: <[email protected]>
Subject: Fact of the day: Magnetic
Message-ID: <[email protected]>
Precedence: Bulk
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PCFET0NUWVBFIGh0bWw+IDxodG1sPiA8aGVhZD4gPG1ldGEgY2hhcnNldD0iVVRGLTgiPiA8L2hl
YWQ+IDxib2R5IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6
ZTogMTZweDsgY29sb3I6ICMzMzM7Ij4gPGRpdiBzdHlsZT0icG9zaXRpb246IGFic29sdXRlOyBs
ZWZ0OiAtOTk5OXB4OyB0b3A6LTk5OTlweDtkaXNwbGF5OiBub25lOyI+SGkgdGhlcmUsPGJyPiBB
IG1hZ25ldGljIGRvbWFpbiBpcyBhIHJlZ2lvbiB3aXRoaW4gYSBtYWduZXRpYyBtYXRlcmlhbCBp
biB3aGljaCB0aGUgbWFnbmV0aXphdGlvbiBpcyBpbiBhIHVuaWZvcm0gZGlyZWN0aW9uLiBUaGlz
IG1lYW5zIHRoYXQgdGhlIGluZGl2aWR1YWwgbWFnbmV0aWMgbW9tZW50cyBvZiB0aGUgYXRvbXMg
YXJlIGFsaWduZWQgd2l0aCBvbmUgYW5vdGhlciBhbmQgdGhleSBwb2ludCBpbiB0aGUgc2FtZSBk
aXJlY3Rpb24uIFdoZW4gY29vbGVkIGJlbG93IGEgdGVtcGVyYXR1cmUgY2FsbGVkIHRoZSBDdXJp
ZSB0ZW1wZXJhdHVyZSwgdGhlIG1hZ25ldGl6YXRpb24gb2YgYSBwaWVjZSBvZiBmZXJyb21hZ25l
dGljIG1hdGVyaWFsIHNwb250YW5lb3VzbHkgZGl2aWRlcyBpbnRvIG1hbnkgc21hbGwgcmVnaW9u
cyBjYWxsZWQgbWFnbmV0aWMgZG9tYWlucy4gVGhlIG1hZ25ldGl6YXRpb24gd2l0aGluIGVhY2gg
ZG9tYWluIHBvaW50cyBpbiBhIHVuaWZvcm0gZGlyZWN0aW9uLCBidXQgdGhlIG1hZ25ldGl6YXRp
b24gb2YgZGlmZmVyZW50IGRvbWFpbnMgbWF5IHBvaW50IGluIGRpZmZlcmVudCBkaXJlY3Rpb25z
LiBNYWduZXRpYyBkb21haW4gc3RydWN0dXJlIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgbWFnbmV0
aWMgYmVoYXZpb3Igb2YgZmVycm9tYWduZXRpYyBtYXRlcmlhbHMgbGlrZSBpcm9uLCBuaWNrZWws
IGNvYmFsdCBhbmQgdGhlaXIgYWxsb3lzLCBhbmQgZmVycmltYWduZXRpYyBtYXRlcmlhbHMgbGlr
ZSBmZXJyaXRlLiBUaGlzIGluY2x1ZGVzIHRoZSBmb3JtYXRpb24gb2YgcGVybWFuZW50IG1hZ25l
dHMgYW5kIHRoZSBhdHRyYWN0aW9uIG9mIGZlcnJvbWFnbmV0aWMgbWF0ZXJpYWxzIHRvIGEgbWFn
bmV0aWMgZmllbGQuIFRoZSByZWdpb25zIHNlcGFyYXRpbmcgbWFnbmV0aWMgZG9tYWlucyBhcmUg
Y2FsbGVkIGRvbWFpbiB3YWxscywgd2hlcmUgdGhlIG1hZ25ldGl6YXRpb24gcm90YXRlcyBjb2hl
cmVudGx5IGZyb20gdGhlIGRpcmVjdGlvbiBpbiBvbmUgZG9tYWluIHRvIHRoYXQgaW4gdGhlIG5l
eHQgZG9tYWluLiBUaGUgc3R1ZHkgb2YgbWFnbmV0aWMgZG9tYWlucyBpcyBjYWxsZWQgbWljcm9t
YWduZXRpY3MuIE1hZ25ldGljIGRvbWFpbnMgZm9ybSBpbiBtYXRlcmlhbHMgd2hpY2ggaGF2ZSBt
YWduZXRpYyBvcmRlcmluZzsgdGhhdCBpcywgdGhlaXIgZGlwb2xlcyBzcG9udGFuZW91c2x5IGFs
aWduIGR1ZSB0byB0aGUgZXhjaGFuZ2UgaW50ZXJhY3Rpb24uIFRoZXNlIGFyZSB0aGUgZmVycm9t
YWduZXRpYywgZmVycmltYWduZXRpYyBhbmQgYW50aWZlcnJvbWFnbmV0aWMgbWF0ZXJpYWxzLiBQ
YXJhbWFnbmV0aWMgYW5kIGRpYW1hZ25ldGljIG1hdGVyaWFscywgaW4gd2hpY2ggdGhlIGRpcG9s
ZXMgYWxpZ24gaW4gcmVzcG9uc2UgdG8gYW4gZXh0ZXJuYWwgZmllbGQgYnV0IGRvIG5vdCBzcG9u
dGFuZW91c2x5IGFsaWduLCBkbyBub3QgaGF2ZSBtYWduZXRpYyBkb21haW5zLjxicj4gQmVzdCw8
L2Rpdj4gPGRpdiBzdHlsZT0iZm9udC1zaXplOiAwOyBsaW5lLWhlaWdodDogMDsiPiAmIzgyMDM7
IDwvZGl2PiA8L2JvZHk+IDwvaHRtbD4=

Like every self-respecting spam sender, they rotate through many sender domains (not exhaustive!):

apiaryapiaries.com
avaspaintinggallery.com
bonfirebeat.com
catnipblissfulhaven.com
chloesgardeninghaven.com
classmerge.com
endurovistawear.com
fragjoystick.com
gainswiftwave.com
ghostlygourd.com
hydroponicseeders.com
lanternlyric.com
mangomysticfusion.com
northchronicle.com
pasturelandplough.com
platformerboss.com
pyxisvoyager.com
raisetyrvalor.com
rockandrender.com
ryeirrigator.com
sifgoldenshine.com
sipandsweater.com
storybookstage.com
strategycrit.com
thruwaymotors.com
tillageacre.com
venusbases.com

But unlike typical spammer, they really go to the extra mile trying to get their spam delivered, immediately retrying from different servers when rejected (apparently some of their IPs are listed on DNSBLs. hmm, I wonder why…):

Jun 23 16:15:36 milek7.pl postfix/smtpd[404910]: connect from mta2.icicleglimmerfrost.com[31.133.27.229]
Jun 23 16:15:38 milek7.pl postfix/smtpd[404910]: NOQUEUE: reject: RCPT from mta2.icicleglimmerfrost.com[31.133.27.229]: 554 5.7.1 Service unavailable; Client host [31.133.27.229] blocked using spam.spamrats.com; SPAMRATS IP Addresses See: http://www.spamrats.com/bl?31.133.27.229; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mta2.icicleglimmerfrost.com>
Jun 23 16:15:39 milek7.pl postfix/smtpd[404910]: disconnect from mta2.icicleglimmerfrost.com[31.133.27.229] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6
Jun 23 16:15:39 milek7.pl postfix/smtpd[404910]: connect from mailc.plowdairy.com[93.120.120.78]
Jun 23 16:15:40 milek7.pl postfix/smtpd[404910]: NOQUEUE: reject: RCPT from mailc.plowdairy.com[93.120.120.78]: 554 5.7.1 Service unavailable; Client host [93.120.120.78] blocked using b.barracudacentral.org; http://www.barracudanetworks.com/reputation/?pr=1&ip=93.120.120.78; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mailc.plowdairy.com>
Jun 23 16:15:41 milek7.pl postfix/smtpd[404910]: disconnect from mailc.plowdairy.com[93.120.120.78] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6
Jun 23 16:15:41 milek7.pl postfix/smtpd[404915]: connect from servidor.classmerge.com[176.113.182.193]
Jun 23 16:15:43 milek7.pl postfix/smtpd[404915]: 53EB982421: client=servidor.classmerge.com[176.113.182.193]
Jun 23 16:15:43 milek7.pl postfix/cleanup[404918]: 53EB982421: message-id=<[email protected]>
Jun 23 16:15:43 milek7.pl postfix/qmgr[404883]: 53EB982421: from=<[email protected]>, size=1301, nrcpt=1 (queue active)
Jun 23 16:15:43 milek7.pl postfix/lmtp[404919]: 53EB982421: to=<[email protected]>, orig_to=<[email protected]>, relay=milek7.pl[dovecot/lmtp], delay=1.8, delays=1.7/0.03/0.05/0.03, dsn=2.0.0, status=sent (250 2.0.0 <[email protected]> dvDAJS+xOmq4LQYA8NhtAw Saved)
Jun 23 16:15:43 milek7.pl postfix/qmgr[404883]: 53EB982421: removed
Jun 23 16:15:44 milek7.pl postfix/smtpd[404915]: disconnect from servidor.classmerge.com[176.113.182.193] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

This is all extremely dumb, because either you “validated” addresses by delivering spam to them, or if destination does content filtering you get your spam rejected and “validation” fails.

Now I’m really curious how they managed to come up with this, because it seems it took an awful lot of effort to do this. I’m guess there’s some stupid SaaS for “validating” email, through it would be funny if it turns out that some LLM agent went off rails.

(actual transactional mails from Pangram are sent through Mailgun)

联系我们 contact @ memedata.com