이미지: blog.elis.cc 화면 갈무리
摘要
- 从2025年到2026年8月,谷歌Workspace的注册页面一直存在一个错误:系统会把正常域名误判为"邮件服务商",从而阻止用户完成注册。
- 乌克兰经济部使用的me.gov.ua域名也遭遇了同样的错误,不得不在谷歌支持社区寻求帮助。
- 一位博主翻查注册页面源代码后发现,问题出在诸如 web\..*、me\..*、alice\..* 这类正则表达式列表上,而且这项校验只在前端生效,禁用后就能顺利完成注册。
- 오류 메시지
- "Enter a valid domain name instead of an email provider"
- 보고자
- 블로거 el1s7, .one TLD 도메인 사용
- 동일 피해 사례
- 우크라이나 경제부 도메인 me.gov.ua
- 원인 규정
- 가입 페이지 프런트엔드의 이메일업체 판별 정규식 목록 (web\..*, me\..*, alice\..* 등)
- 검증 위치
- 클라이언트 사이드(프런트엔드)만 검증, 서버 사이드 검증 없음
- 구글 대응
- 정확한 원인을 파악하지 못한 채 다른 도메인 사용을 권유
- 게시 시점
- 원문 2025년 작성, 2026년 8월 업데이트로 문제 지속 확인
"您的域名是邮件服务商"
博主el1s7在尝试注册谷歌Workspace时,刚输入自己的域名就碰上了一个陌生的错误提示。屏幕上显示"Enter a valid domain name instead of an email provider"(请输入有效的域名,而非邮件服务商),但这个域名其实是他花高价续费的正规域名,从未有过滥用记录。尽管用的是.one这种正式的顶级域名(TLD),谷歌却把它误认成了邮件服务商的地址。
谷歌官方文档中找不到任何关于这个错误的说明,博主搜索后发现,有不少人遇到同样问题并在社区里求助。其中一条谷歌支持社区帖子显示,乌克兰经济部用自己的域名me.gov.ua注册Workspace时也碰上了一模一样的错误。
三位客服接线员,以及那句"您试过别的浏览器吗"
博主最终联系了谷歌Workspace客服。好几位接线员反复问他"有没有试过换个浏览器",他一再解释自己已经试过之后,才被转接到高级支持人员Karen那里。结果Karen也问了同样的问题,让他换台设备再试试。之后他又被要求录屏提交,以便产品工程师排查,但几天后再次尝试,错误依然存在。一周后收到的答复是:谷歌方面也搞不清具体原因,建议他换个域名。
藏在源代码里的正则表达式列表
正当博主考虑放弃谷歌、转投微软时,他最后决定亲自打开注册页面的源代码看看。结果发现,错误其实来自本地的输入校验函数。这个函数会把输入的域名与一份"疑似邮件服务商"的正则表达式列表逐一比对,而列表里有好几条规则让人摸不着头脑。
| 正则表达式 | 被误判过滤的域名示例 | 备注 |
|---|---|---|
web\..* | 所有以web.开头的顶级域名 | 博主的.one域名正是撞上这条规则才被拦下注册 |
me\..* | 以me.开头的域名及子域名 | 乌克兰经济部的me.gov.ua也是栽在这条规则上 |
alice\..* | 以alice.开头的域名 | 博主表示完全找不到这条规则存在的依据 |
web\..*这条规则,直接把所有以web.开头的域名统统归类为邮件服务商。me\..*规则则连子域名是me的地址也一并拦下,这也正是使用me.gov.ua域名的乌克兰经济部会撞上同一个错误的原因。
服务器不拦,只是页面拦住了
博主在浏览器开发者工具里强行禁用了这个校验函数,结果不出所料——关掉校验之后,他顺利通过了域名输入环节,完成了注册。也就是说,这项校验只存在于前端页面,服务器端根本没有拦截,问题恰恰出在这套校验逻辑本身,把正常域名错误地归类成了邮件服务商。博主猜测,乌克兰经济部当初遇到这个问题后可能转投了微软365,不过这只是他个人的推测,并未得到证实。
编辑视角
这个案例有意思的地方,不在于这个bug本身,而在于它是怎么被"制造"出来的。这条规则最初大概是为了拦截像web.de、gmx、mail.ru这类出售免费邮箱服务的域名,防止它们被误当成企业账号,可是随着时间推移,它逐渐演变成了web.[任意顶级域名]、me.[任意顶级域名]这种过于宽泛的一张大网。至于alice..*这一条,连博主本人都没查出个所以然,这其实也说明:某个人当年随手加了一条规则,之后就再也没人回头检查过。
对长期维护过SaaS注册表单的人来说,这种情况其实并不陌生。校验逻辑一开始可能只是几行简单的黑名单,但随着负责人几经更替、年复一年地没人做审计,就这样被搁置下来。问题在于,这次出问题的是一家大公司的核心注册流程。一段能影响到连政府机构域名都被误拦的高影响力逻辑,居然只靠前端JavaScript的一行代码撑着,服务器端根本没有相应的校验,这一点也格外值得注意。校验只存在于客户端,就意味着靠开发者工具就能绕过去,从安全角度看,这种设计相当粗糙。
如果在注册Workspace或类似SaaS服务时,用公司域名遇到类似的错误,与其联系客服等上几周,不如直接打开浏览器开发者工具查看注册页面的脚本,这可能是更快的解决办法。当然,这种方法不适合推荐给所有用户,而且需要靠这种方式绕过去,本身就说明服务方存在问题。这次事件已经在Hacker News上引发热议,谷歌调整这份正则表达式列表的可能性是存在的,但会不会同时补上服务器端的校验,还有待观察。
评论