Korokithakis Urges Developers to Scrap Email Validation Regex

FOSDEM

Because strict syntax rules break on valid edge cases and evolving domains, software should only check for an at sign and verify delivery through an outbound confirmation link.

AI-assisted summary of So you think you can validate email addresses A journey down RFC5321 — original source. Check the original for full context.

Source published: 2018-02-10

Key ideas

Stavros Korokithakis argues that attempting to validate email addresses using complex regular expressions is fundamentally broken because human intuition consistently conflicts with RFC 5321 specifications. (7:22)
Under email RFCs, seemingly bizarre patterns like quoted spaces, embedded comments in parentheses, and unadorned decimal IPv4 addresses are standards-compliant, while consecutive dots or unquoted leading/trailing dots remain invalid. (1:46)
The only reliable, future-proof method to validate an email address is verifying the presence of an '@' sign and dispatching a confirmation link for the user to click. (7:22)
Overly strict form validation frequently locks out legitimate users with valid plus-addressing, long top-level domains, or internationalized domain names (IDNs). (8:04)

Detailed notes

## Background This lightning talk by Stavros Korokithakis was published on YouTube by FOSDEM on February 10, 2018. Recorded live at FOSDEM 2018 in room K.1.105 (La Fontaine), the session explores the intricacies and RFC standards behind validating email addresses.

## TL;DR Stavros Korokithakis leads a fast-paced audience quiz testing bizarre edge cases permitted under RFC 5321, from comments inside parentheses to quoted spaces and unadorned decimal IPv4 hostnames. He demonstrates that human intuition almost always fails when trying to parse standards-compliant email formats, rendering complex regex validation routines fragile and counterproductive. Ultimately, he argues that developers should stop over-engineering syntax checks altogether: the only pragmatic, future-proof approach is to verify the presence of an '@' sign and confirm the address by sending a verification link.

## Atmosphere & style The presentation is energetic, irreverent, and packed with dry wit, opening with deadpan humor about the utility of the talk and an immediate breakdown of the slide remote. The atmosphere feels like an interactive comedy set for software engineers, driven by lively audience participation where attendees shout out conflicting answers only to be baffled by obscure RFC specifications. Korokithakis's playful exasperation with overly strict web forms creates an engaging, communal camaraderie that leaves the audience laughing while embracing a refreshingly simple engineering lesson.

## Bulletin - [07:22](https://www.youtube.com/watch?v=xxX81WmXjPg&t=442s) Stavros Korokithakis argues that attempting to validate email addresses using complex regular expressions is fundamentally broken because human intuition consistently conflicts with RFC 5321 specifications. - [01:46](https://www.youtube.com/watch?v=xxX81WmXjPg&t=106s) Under email RFCs, seemingly bizarre patterns like quoted spaces, embedded comments in parentheses, and unadorned decimal IPv4 addresses are standards-compliant, while consecutive dots or unquoted leading/trailing dots remain invalid. - [07:22](https://www.youtube.com/watch?v=xxX81WmXjPg&t=442s) The only reliable, future-proof method to validate an email address is verifying the presence of an '@' sign and dispatching a confirmation link for the user to click. - [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) Overly strict form validation frequently locks out legitimate users with valid plus-addressing, long top-level domains, or internationalized domain names (IDNs).

## Key takeaways - [00:06](https://www.youtube.com/watch?v=xxX81WmXjPg&t=6s) Most developers have written email parsing and validation logic, yet almost universally misunderstand the full complexity of email RFC specifications. - [01:46](https://www.youtube.com/watch?v=xxX81WmXjPg&t=106s) Leading dots, trailing dots, and consecutive dots in an unquoted local part violate standard SMTP specifications and are invalid. - [01:46](https://www.youtube.com/watch?v=xxX81WmXjPg&t=106s) Uncommon punctuation characters such as asterisks in the local part are fully standards-compliant. - [01:46](https://www.youtube.com/watch?v=xxX81WmXjPg&t=106s) Parentheses in certain locations represent RFC-compliant comments that mail servers deliberately ignore. - [01:46](https://www.youtube.com/watch?v=xxX81WmXjPg&t=106s) Quoted strings allow spaces and '@' symbols inside the local part, and a quoted space can even serve as the entire local part. - [01:46](https://www.youtube.com/watch?v=xxX81WmXjPg&t=106s) Bracketed IPv6 hostnames and unadorned decimal representations of IPv4 addresses are completely valid destination hosts under the specifications. - [07:22](https://www.youtube.com/watch?v=xxX81WmXjPg&t=442s) Real-world implementations frequently diverge from RFC theory, such as RFC 5321 mandating case sensitivity in the local part while major providers treat it as case-insensitive. - [07:22](https://www.youtube.com/watch?v=xxX81WmXjPg&t=442s) Complex regular expressions for email validation create false negatives that block legitimate users and should be discarded. - [07:22](https://www.youtube.com/watch?v=xxX81WmXjPg&t=442s) The optimal validation flow requires only two steps: verify that the string contains an '@' sign, and send a message requiring user confirmation. - [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) Round-trip email confirmation provides superior security compared to regex validation by verifying true inbox access without producing false positives. - [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) Websites commonly reject valid plus-addressed emails ('+') because engineers test against narrow, conventional address samples without reading RFC standards. - [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) Enforcing rigid length or formatting assumptions against domain names frequently breaks support for valid multi-letter TLDs and intranet hosts. - [13:24](https://www.youtube.com/watch?v=xxX81WmXjPg&t=804s) Attempting to enforce strict negative rules on the local-part adds unnecessary maintenance overhead and risks breaking when internet standards evolve. - [14:43](https://www.youtube.com/watch?v=xxX81WmXjPg&t=883s) Internationalized domain names (IDNs) and Cyrillic characters can visually mimic ASCII punctuation while resolving as fully valid domains.

## Detailed walkthrough ### [00:06](https://www.youtube.com/watch?v=xxX81WmXjPg&t=6s) Introducing “Electronic Mail” and Audience Calibration

Stavros Korokithakis begins his lightning talk at FOSDEM 2018 with tongue-in-cheek humor, declaring that while his last name remains unpronounceable to the room, he has arrived to discuss the single most important topic of the entire conference. Looking out at the packed audience in room K.1.105, he deadpans, “I'm afraid you have grossly overestimated how useful this talk is going to be but that's fine.” He mock-introduces a supposed cutting-edge technology named “electronic mail,” explaining to the crowd that it lets people instantly send letters to pen pals all across the world over the internet.

He tests the room by asking for a show of hands: how many people have an account with services like Hotmail or AOL, how many have sent or received an email, how many have written software that uses email, and finally, how many have written software tasked with parsing and validating an email address. A significant number of hands go up for parsing. Stavros remarks that every single one of those developers will need this talk. After his remote clicker immediately refuses to work—prompting the joke that while electronic mail works, presentation remotes do not—he proceeds to flip slides manually and invites the entire room to participate in a rapid-fire quiz by shouting whether each displayed address is valid or invalid.

[01:46](https://www.youtube.com/watch?v=xxX81WmXjPg&t=106s) The Rapid-Fire RFC 5321 Validation Quiz

Stavros walks the audience through slide after slide of email addresses, exposing how deeply human intuition conflicts with RFC specifications. Basic formats pass easily, including addresses containing a plus sign or a single dot. However, edge cases swiftly trip up the audience:

- **Leading and trailing dots**: Having a dot at the beginning or end of the local part renders an address invalid. Stavros quips that anyone shouting valid needs tutoring classes. - **Consecutive dots**: Two dots in a row (e.g., `..`) are completely invalid according to the RFCs. - **Special characters and symbols**: An asterisk or other uncommon punctuation characters in the local part are fully standards-compliant and valid. - **Parentheses**: Parentheses inside an unquoted local part make an address invalid. - **RFC comments**: When parentheses enclose text in certain locations, they denote RFC-compliant comments. These comments are standards-compliant, valid, and completely ignored by mail servers. The audience murmurs in disbelief, prompting Stavros to marvel along with them: “Who wrote this stuff?” - **Double `@` signs without quotes**: Invalid under standard SMTP specifications. When an audience member asks whether this is an SMTP-level rule or user-facing mail client behavior, Stavros clarifies that this is directly from the RFC specifications at the SMTP level. - **Quoted strings**: An `@` sign or a space enclosed in double quotes is completely valid. A space can even serve as the entirety of the local part if quoted. - **Quoting mechanics**: Multiple quoted segments must be separated by dots; adjacent unseparated quotes are invalid. However, if backslash escaping is used inside properly dot-separated quotes, the address is valid. Stavros promises: “This is if you send email to this I will reply to you I will literally do it.” - **Escaping spaces without quotes**: Attempting to escape a space with a backslash without wrapping it in quotation marks remains invalid. - **Host formats**: Bracketed IPv6 hostnames are valid. Single-label top-level domains (TLDs) without an additional domain name can also be valid if the TLD resolves or accepts delivery. Unicode characters in addresses are standard-compliant. - **Decimal IPv4 addresses**: An address ending in a raw numeric string like an unadorned decimal representation of an IPv4 address is fully valid. Those who guessed valid thinking it was an IPv6 address were “correct for the wrong reasons.”

[07:22](https://www.youtube.com/watch?v=xxX81WmXjPg&t=442s) The One True Validation Rule

Following the quiz, Stavros explains that trying to validate email addresses using complex regular expressions or strict syntax trees is fundamentally misguided. Real-world implementations diverge from RFC theory anyway; for example, RFC 5321 specifies that the local part should be treated as case-sensitive, yet virtually no modern mail provider enforces case sensitivity.

```mermaid flowchart TD accTitle: Email Validation Flow accDescr: The practical email validation process proposed by Stavros Korokithakis.

subgraph InputCheck["Form Submission"] A["User submits email address"] --> B{"Contains '@' sign?"} end

subgraph Verification["Verification Phase"] B -- "No" --> C["Reject input immediately"] B -- "Yes" --> D["Send email with verification link"] D --> E{"User clicks confirmation link?"} E -- "Yes" --> F["Address is valid"] E -- "No / Bounces" --> G["Address is invalid"] end ```

Because true validity depends entirely on delivery, mail exchangers, and human inbox ownership, Stavros presents the only rule developers actually need: “How do we validate an email address? We don't, we just check if there's an at sign in there and if there is one we say okay you know passes the first check, you send an email to it and then you wait for the user to click the link or whatever.” He passionately warns web developers against blocking unusual addresses: “So if I see another signup form that says that my address is not valid I'm gonna hunt you down whoever it is and I'm gonna show you the presentation again.”

[08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) Q&A: Libraries, Plus Signs, TLDs, and Edge Cases

Stavros opens the floor to audience questions, addressing edge cases, historical quirks, and developer resistance:

- **Emojis and Standards Evolution**: When asked about emojis, Stavros jokes that adding them would be cheating, though it might be a fun idea. When asked if the standards are still shifting, he confirms that while specifications continue to develop over time, keeping the rule dead simple guarantees future compatibility. - **Validation Libraries**: Asked which software library developers should use, Stavros deadpans that every language already includes the ultimate library: checking `if '@' in string`. - **System Complexity**: An attendee asks whether email validation truly needs to be so complex. Stavros responds that sending messages across the globe requires accepting concessions; verifying delivery via an outgoing link is genuinely the simplest and most foolproof method available. - **Why Systems Reject Plus Signs**: An audience member asks why so many production websites reject addresses containing plus signs (`+`) despite widespread support by major providers. Stavros attributes this to developer ignorance: engineers test against ten conventional addresses that all look the same, assume anything outside that narrow window is erroneous, and never bother to read the standard. - **Long TLD Difficulties**: A member of the audience laments owning a four-letter top-level domain that web forms constantly reject. Stavros sympathizes, joking that anyone with a five-letter TLD is completely doomed and should just give up and get a Gmail address instead. - **Security Implications**: Asked whether accepting any string with an `@` sign introduces security vulnerabilities, Stavros counters that it is actually the most secure approach possible because it requires zero assumptions, avoids regex pitfalls, and produces zero false positives or false negatives by requiring actual round-trip verification: “No actually my rule is the most secure of all because you will actually send an email and the user will have to reply back and make sure that they received the email before you can consider them valid.” - **Intranet and Local Hostnames**: An attendee asks whether addresses on private intranets or non-public domains are valid. Stavros confirms that as long as the sending host can resolve the destination machine, the address is valid, reinforcing why a simple `@` check remains the only universal standard.

[13:24](https://www.youtube.com/watch?v=xxX81WmXjPg&t=804s) Validating Local-Parts vs. Checking for the At Sign

An audience member opens the Q&A session by pointing out that while finding universal rules in email specifications is notoriously difficult, there still appear to be some concrete constraints on the local-part. The attendee asks whether it is simply a waste of time to validate those extra local-part rules, or if developers should just stick to the simplest possible heuristic—checking whether there is an `@` sign—given how flexible standards and server configurations can be. Stavros Korokithakis acknowledges that this is a valid dilemma, explaining that developers certainly can filter out patterns if they are absolutely certain they are invalid to prevent completely unreachable addresses from hitting their servers. However, he cautions that trying to enforce strict negative rules usually backfires due to the rapid evolution of Internet specifications and domain registries. Stavros Korokithakis summarizes his practical philosophy: “I think them yeah the most general way to do it is just check for the add sign because you never know what kind of crazy new domains there will be and things like that so just send the email and be done with it.”

The floor then shifts to another audience member asking about domain routing, host movements, and whether checking without an `@` sign makes any sense at all. Stavros agrees that hosts move and infrastructure changes unexpectedly over time. Joking with the crowd about why developers overcomplicate the problem in the first place, he laughs, “I don't know some people just calm presentations and spread misinformation,” teasing the industry-wide tendency of tech talks and blog posts to invent complex, broken regular expressions rather than sticking to sending a verification email.

- Developers can write negative checks for known invalid patterns only if they are entirely certain the target address can never be reached, but doing so adds maintenance overhead. - Because new top-level domains, internationalized domain names, and edge-case hosting setups are constantly introduced, checking for an `@` symbol and dispatching a confirmation message remains the only robust validation strategy.

```mermaid flowchart TD accTitle: Email Validation Strategy accDescr: Flowchart illustrating the recommended strategy of checking for an at sign and sending a verification email versus over-validating syntax.

subgraph InputCheck["Minimal Client/Server Validation"] A["User submits email address"] --> B{"Contains '@' sign?"} end

subgraph Verification["Delivery & Resolution"] B -- "No" --> C["Reject address immediately"] B -- "Yes" --> D["Send verification message via SMTP"] D --> E{"User clicks link / confirms receipt?"} E -- "Yes" --> F["Address is valid & verified"] E -- "No" --> G["Address unconfirmed / unreachable"] end ```

[14:43](https://www.youtube.com/watch?v=xxX81WmXjPg&t=883s) Pathological Cases, Unicode Domains, and the Single Rule

The Q&A takes a humorous turn when an audience member poses an extreme edge case: what happens if the input contains only a single quoted `@` symbol as part of a quoted local-part without a standard domain separator? Stavros Korokithakis dismisses anyone intentionally trying to submit such an address: “then you don't deserve to be using the Internet and computers so yeah you're fine you deserve whatever you get a next question”

Another attendee asks whether it is legally permissible under the specifications to have punctuation, such as an exclamation mark, immediately following the `@` symbol in the remote/domain part. Stavros pauses to consider whether remote parts allow such syntax, admitting that while it seems unlikely at first glance, the rapid expansion of internationalized domain names (IDNs) means that unexpected characters or Cyrillic symbols might visually resemble quotation marks or punctuation while resolving as completely valid Unicode domains. He remarks that their own registration forms had historically rejected valid inputs before being updated just two days prior to accommodate real-world variability.

Seeing no further hands, Stavros closes the talk by rallying the room around a single, pragmatic takeaway. Stavros Korokithakis declares: “it looks like everybody is happy with one simple rule great check for a bloody @ sign this is my this is my invalid email address and this is my my website you can see stuff there and if you want I'll be around”

- Internationalized domain names mean that visual characters resembling ASCII punctuation marks could actually be valid Unicode domain components. - The ultimate conclusion of the journey through RFC 5321 is to avoid brittle, multi-line regular expressions entirely and rely strictly on checking for a single `@` sign combined with outbound email delivery.

## Mentioned Stavros Korokithakis, FOSDEM, RFC 5321, SMTP, Hotmail, AOL, Gmail, IPv4, IPv6

## Video description by Stavros Korokithakis

At: FOSDEM 2018 Room: K.1.105 (La Fontaine) Scheduled start: 2018-02-04 16:30:00+01

[Source](https://www.youtube.com/watch?v=xxX81WmXjPg)

中文简报

Korokithakis呼吁开发者弃用电子邮件验证正则表达式由于严格的语法规则会因合法的边缘用例和不断演变的新域名而失效，软件应仅检查是否存在“@”符号，并通过发送确认链接来验证投递。 Stavros Korokithakis主持了一场快节奏的现场观众测验，测试了RFC 5321所允许的各种离奇边缘用例，涵盖圆括号内的注释、带引号的空格以及纯十进制IPv4主机名等。他指出，在尝试解析符合标准的电子邮件格式时，人类直觉几乎总是出错，这使得复杂的正则表达式验证例程既脆弱又适得其反。最终，他认为开发者应彻底停止过度设计语法检查：唯一务实且面向未来的方法，就是仅验证是否存在“@”符号，并通过发送验证链接来确认该地址。 Stavros Korokithakis指出，尝试使用复杂的正则表达式来验证电子邮件地址从根本上就是行不通的，因为人类直觉始终与RFC 5321规范相冲突。 (7:22) 在电子邮件RFC规范下，带引号的空格、圆括号中内嵌的注释以及纯十进制IPv4地址等看似离奇的格式实际上均符合标准，而连续的点号或未加引号的前导/尾随点号仍属无效。 (1:46) 验证电子邮件地址唯一可靠且面向未来的方法，是核验是否存在“@”符号并发送确认链接供用户点击。 (7:22) 过于严格的表单验证往往会将使用合法的加号寻址（plus-addressing）、长顶级域名或国际化域名（IDN）的正常用户拒之门外。 (8:04)

Reading summary

At FOSDEM 2018, Stavros Korokithakis argued that developers should abandon complex syntactic validation and regular expressions for email addresses, proposing instead that systems simply verify the presence of an "@" sign and test deliverability by sending a confirmation link. RFC Specifications Conflict with Developer Intuition (1:46) Korokithakis demonstrated through an audience quiz that RFC 5321 and related email standards routinely defy developer expectations. While basic structures pass common intuition, RFC specifications permit numerous obscure formats: asterisks and other uncommon punctuation in the local part are valid, as are bracketed IPv6 hostnames, Unicode characters, and raw decimal representations of IPv4 addresses. Furthermore, parentheses enclosing text are validly treated as ignored RFC comments, and quoted strings allow both double "@" symbols and spaces—even permitting an entire local part to consist of a quoted space if properly formatted. Over-Validation and Real-World Implementation Disconnects (7:22) Attempting to model strict syntactic rules is fundamentally flawed because real-world email infrastructure diverges from specification theory. For instance, while RFC 5321 specifies that the local part should be treated as case-sensitive, modern mail providers universally ignore case distinctions. Similarly, developer ignorance leads many production forms to reject legitimate addresses containing plus signs ("+") or longer top-level domains simply because engineers tested only a narrow set of conventional addresses. Korokithakis noted that attempting to enforce negative filtering rules inevitably backfires due to the constant introduction of new top-level domains, internationalized domain names (IDNs), and local network routing rules. Because Unicode characters and Cyrillic symbols in IDNs can visually resemble ASCII punctuation while remaining fully routable, rigid regular expressions create false negatives by rejecting valid users. Delivery Verification as the Only Robust Rule (8:04) Because true validity depends entirely on whether a destination host can resolve, receive messages, and return them to an actual inbox, Korokithakis asserted that software should use a single heuristic: checking whether the input contains an "@" symbol. Once that minimal criterion is met, the system should dispatch an email with a verification link and wait for the user to confirm receipt. Addressing security and implementation concerns, Korokithakis maintained that this two-step process—presence of an "@" sign followed by round-trip confirmation—is more secure than complex syntax parsing. It eliminates regular expression pitfalls, accommodates evolving standards, and avoids both false positives and false negatives by proving actual operational reachability. While developers can technically write negative filters for patterns they know are unreachable, Korokithakis concluded that trying to outguess changing standards, IDNs, and server configurations creates needless maintenance. Operational delivery via an outbound verification message remains the only reliable test of whether an email address is valid.

精炼阅读摘要

Stavros Korokithakis 在 FOSDEM 演讲中指出，试图使用复杂正则表达式或语法分析树验证电子邮件地址在工程上注定会失败；邮箱地址的有效性最终取决于网络投递与收件箱所有权，开发者只需检查是否存在“@”符号，并依赖发送验证链接完成闭环确认。 RFC 5321 规范与人类直觉的冲突 (1:46) RFC 5321 等技术规范定义了大量反直觉的合法与非法格式，使开发者单凭直觉设计的校验规则极易误判。在本地部分（local-part），开头、结尾包含圆点或出现连续双圆点（如“..”）在规范中均属非法；然而，星号等不常见的标点符号却完全合规。更为反常的是，用圆括号包裹的文本在标准中属于注释（comment），不仅合法而且会被邮件服务器直接忽略。此外，包含空格或“@”的本地部分在双引号包裹下完全合法，但在无引号时即使使用反斜杠转义依然非法。在主机名（domain）部分，带方括号的 IPv6 地址、未加修饰的纯十进制 IPv4 地址，以及能够解析或接受投递的单标签顶级域名（TLD）均符合规范。这些冷僻语法的存在表明，试图在客户端或服务端穷举所有有效语法结构不仅耗时费力，且极容易与官方标准发生偏离。生产环境过度校验的工程弊病 (8:04) Stavros 指出，许多生产系统对合规地址的错误拦截，主要源于开发者的认知盲区。许多工程师仅基于少数常见的邮箱格式编写测试用例，将超出认知范围的输入一概判定为错误，而从未完整阅读技术标准。例如，主流邮件服务商普遍支持在本地部分使用加号（“+”）进行子地址别名标记，但大量在线表单仍将其拦截；拥有四位或更长字符顶级域名的用户也频繁遭遇注册障碍。此外，理论规范与真实投递环境之间存在明显脱节。虽然 RFC 规范规定本地部分应区分大小写，但现代邮件服务商在实际运行中几乎从不强制执行大小写敏感策略。这种现实分歧进一步证明，脱离投递测试而单纯进行静态文本匹配并无实际意义。检查 @ 符号并投递的极简验证法则 (7:22) 针对邮件校验难题，Stavros 提出了极简的处理法则：系统只需验证输入字符串中是否包含一个“@”符号；若包含，则直接向该地址发送一封包含验证链接的邮件，并等待用户点击确认。只有当用户通过该链接回传确认信号时，系统才正式将其标记为有效地址；若邮件发生退信或未获响应，则判定无效。针对这种宽松输入是否会引入安全漏洞的疑问，Stavros 强调该方法恰恰是最安全的策略。它彻底规避了复杂的正则表达式带来的安全缺陷（如正则拒绝服务风险 ReDoS），消除了开发人员的主观臆断，并通过端到端的通信闭环实现了零误报与零漏报。只要发送方能够解析目标机器，该逻辑在局域网私有主机名上也同样成立。域名标准演进与负向过滤的维护陷阱 (13:24) 在问答环节中，针对是否应针对已知的非法模式编写负向过滤规则，Stavros 警告称严格的负向约束往往会随着互联网标准的演进而适得其反。随着国际化域名（IDN）和新型顶级域名的快速扩展，部分非拉丁字符（如西里尔字母）在视觉上可能与引号或标点符号相似，但实际上属于完全合法的 Unicode 域名；若在前端进行硬性拦截，将直接阻断正常用户的访问。 Stavros 认为，技术社区中广泛流传的多行复杂正则表达式往往是在传播错误信息。互联网基础设施和域名路由处于动态变动之中，开发者试图通过本地代码穷尽验证规则只会带来无休止的维护负担，唯有依赖基础的“@”检查结合实际 SMTP 投递，才是具备未来兼容性的长远策略。 Stavros Korokithakis 总结认为，电子邮件验证的本质是投递可行性与身份归属问题，而非语法文本匹配。尽管彻底放弃本地部分格式检查的做法挑战了传统表单验证的惯性思维，但在面对不断演进的国际化标准与复杂现实环境时，依赖双向邮件确认的极简验证依然是兼顾鲁棒性与包容性的最佳工程实践。

Detailed notes — zh

## Background 该视频由 FOSDEM 于 2018 年 2 月 10 日发布在 YouTube 平台上。页面描述显示，这是 Stavros Korokithakis 在 FOSDEM 2018 大会（K.1.105 演讲室）上进行的分享，主题为围绕 RFC 5321 协议探讨电子邮件地址校验的技术之旅。 ## TL;DR 演讲者 Stavros Korokithakis 针对开发者长期以来的痛点，通过现场全员参与的“判定邮箱是否合法”互动游戏，剖析了 RFC 5321 等邮件标准中反直觉的冷门语法规则。演讲展示了带注释括号、双引号转义、十进制 IPv4 及各类看似荒诞却完全合规的地址格式，说明了用复杂正则表达式覆盖所有标准的徒劳无功。最后他提出最具实操性的极简结论：开发者只需检查字符串是否包含“@”符号，并通过发送带激活链接的确认邮件来完成真正的可用性校验。 ## Atmosphere & style 整场演讲洋溢着极客式幽默与自嘲风格，节奏欢快且充满互动张力。Stavros 像一位风趣的课堂讲师，每次揭晓出人意料的 RFC 规范答案时，都会引来全场观众的会心大笑与惊叹。台下技术从业者在面对古怪案例时从困惑、被打脸到最终释然，现场氛围轻松热烈，将原本枯燥晦涩的协议规范讲得生动解压。 ## Bulletin - [07:23](https://www.youtube.com/watch?v=xxX81WmXjPg&t=443s) 试图通过复杂的正则表达式或语法解析器完全覆盖 RFC 5321/5322 规范纯属徒劳，因为标准中包含带引号空格、十进制 IPv4 乃至括号注释等大量反直觉的合法格式。 - [07:23](https://www.youtube.com/watch?v=xxX81WmXjPg&t=443s) 工程落地的最佳实践是极简原则：只需检查字符串中是否存在“@”符号，并通过发送带有确认链接的验证邮件来检验邮箱的有效性与可达性。 - [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) 过度严格的本地校验往往源于开发者的经验不足，盲目拦截加号（+）或长顶级域名会导致高误伤率，直接损害真实用户的注册体验。 - [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) 只验证“@”并直接投递邮件的策略在有效性判定上具备零误报与零漏报，尽管产生发信成本，但这属于业务运行不可避免的基础设施开销。 ## Key takeaways - [01:58](https://www.youtube.com/watch?v=xxX81WmXjPg&t=118s) RFC 规范允许 local-part 中使用加号（+）及多种特殊符号，但未经引号包裹时禁止以点号开头或包含连续点号（..）。 - [01:58](https://www.youtube.com/watch?v=xxX81WmXjPg&t=118s) 在 RFC 标准中，未转义的圆括号内容被定义为注释（Comments），邮件服务器在处理投递时会直接忽略括号及其内部文本。 - [03:45](https://www.youtube.com/watch?v=xxX81WmXjPg&t=225s) local-part 一旦使用双引号包裹，此前非法的字符（如 @、空格甚至是 Unicode 字符）便会立即转为完全合法。 - [03:45](https://www.youtube.com/watch?v=xxX81WmXjPg&t=225s) 双引号与外部普通字符混合使用时，RFC 规定必须使用点号（.）进行显式分隔，否则依然视为非法格式。 - [03:45](https://www.youtube.com/watch?v=xxX81WmXjPg&t=225s) 空格字符即使经过反斜杠转义，在未被双引号整体包裹的情况下依然属于非法语法。 - [06:16](https://www.youtube.com/watch?v=xxX81WmXjPg&t=376s) 域名部分不仅支持以方括号包裹的 IPv6 地址和单个顶级域名（TLD），甚至还允许使用十进制整数形式来表示 IPv4 地址。 - [07:23](https://www.youtube.com/watch?v=xxX81WmXjPg&t=443s) RFC 规定的“local-part 区分大小写”等要求在现代互联网服务商的实际实现中几乎未被严格执行，规范与现实严重脱节。 - [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) 任何针对电子邮件格式的前端或本地校验库，其实质价值都不如“判断字符串中是否包含 @ 并发信验证”来得稳健有效。 - [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) 现实中大量网站拦截带有加号或多位字母顶级域名的地址，本质上是开发者误以为所有邮箱都遵循单一简单外观的认知偏见。 - [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) 发送确认邮件是确保邮箱有效性的终极手段，不仅兼具内网和非公开域名的普适性，还能彻底消除格式误判造成的用户流失。 - [13:24](https://www.youtube.com/watch?v=xxX81WmXjPg&t=804s) 对于未完全确信为不可达的古怪地址，过度拦截远比直接尝试投递更具破坏性，极简校验策略更能适应不断演进的现代域名体系。 - [14:43](https://www.youtube.com/watch?v=xxX81WmXjPg&t=883s) 面对仅在引号内包含“@”且缺失域名等极端恶意的边界情况，系统无需在解析层过度妥协，直接报错亦属合理应对。 ## Detailed walkthrough ### [00:06](https://www.youtube.com/watch?v=xxX81WmXjPg&t=6s) 开场与“前沿技术”电子邮件介绍主持人 Larry 介绍了讲者 Stavros Korokithakis，并指出本场演讲探讨的是每个系统管理员都曾遭遇的噩梦：电子邮件地址校验。Stavros 登台后便以幽默自嘲破题，坦言自己的姓氏在听众的母语里几乎无法发音，所以索性略过。他半开玩笑地宣称这可能是整场大会最重要的演讲，但看到台下座无虚席，又调侃道：“I also see many people here so I'm afraid you have grossly overestimated how useful this talk is going to be but that's fine.”（看到来这么多人，我担心你们严重高估了这场演讲的实用价值，不过没关系。）随后，Stavros 煞有介事地向观众科普起一项“全新技术”——电子信件（Electronic Mail），戏称这是一种能让你通过互联网与世界各地的笔友瞬间通信的工具。他向观众互动提问：有多少人用过 Hotmail 或 AOL 等邮箱？有多少人写过发信软件？又有多少人亲自写过解析和验证电子邮件地址有效性的代码？看到大批听众举手，Stavros 笃定地表示，在座的每一个人都急需这场演讲。由于翻页笔故障，他在现场手动切换幻灯片，开启了整场演讲的核心互动测试：每一页展示一个电子邮件地址，全场观众大声喊出它是“有效（Valid）”还是“无效（Invalid）”。 ```mermaid flowchart TD accTitle: 演讲开场与互动环节流程 accDescr: 展示 Stavros 演讲从开场破题到进入观众互动竞猜环节的递进过程。 subgraph Intro["开场介绍"] A["主持人介绍：系统管理员的宿命难题"] --> B["Stavros 自嘲与调侃'高估实用性'"] B --> C["戏称 Email 为'连接笔友的新技术'"] end subgraph AudienceCheck["现场调查与设备准备"] D["举手调查：谁写过 Email 解析与校验器？"] --> E["翻页笔故障，改用手动翻页"] end subgraph Challenge["核心互动"] F["规则：逐页亮出地址，全场大声喊 Valid / Invalid"] end Intro --> AudienceCheck --> Challenge ``` --- ### [01:58](https://www.youtube.com/watch?v=xxX81WmXjPg&t=118s) 现场大考：常见符号、点号与括号陷阱第一组测试从常规格式迅速切入到极易被误判的 RFC 语法细节中： - **标准地址**：普通合法地址通过后，紧接着展示无域名形式，全场迅速判定为非法。 - **加号（`+`）**：形如带标签的地址，多数人都知道加号在 RFC 中完全合法。 - **点号（`.`）位置规则**：正常的分段点号是合法的；但若将点号放在最前面（以点开头），则是非法的。Stavros 对此打趣道：“If you've said valid you need to come to me for classes for tutoring.”（要是谁说这个有效，那你得找我补课了。） - **连续点号（`..`）**：两个点号连在一起（如 `..`）同样非法，RFC 禁止未经引号包裹的连续点。 - **过度聪明的误判**：针对某个看似合法实则错误的边界案例，台下有人误判为有效，Stavros 调侃道：“If you said valid you should feel bad because you're trying to be too clever but you weren't.”（如果你们答了有效，应该感到惭愧，因为你们自作聪明但其实根本没搞对。） - **特殊字符与星号（`*`）**：地址中包含星号以及各类看起来“像坏词”的特殊符号是合法的，RFC 允许在 local-part 出现大量不常见的 ASCII 特殊符号。 - **括号与注释语法（Comments）**：当屏幕上出现圆括号时，台下观众犹豫不决。Stavros 揭示了 RFC 的惊人规定：单纯出现未转义的圆括号是“非法”的；但如果在括号中包裹内容，它在 RFC 规范中居然被定义为**注释（Comment）**！这种带注释的地址完全符合 RFC 标准，邮件服务器会直接忽略括号及其内容。台下观众发出“这都是谁写的标准”的惊呼，Stavros 笑着证实这完全是标准的 RFC 行为。 --- ### [03:45](https://www.youtube.com/watch?v=xxX81WmXjPg&t=225s) 进阶难题：多重 `@`、引号包裹与转义机制随着案例逐步深入，测试进入了针对引号和转义字符的复杂规则阶段。现场有观众提问这些规则究竟是 SMTP 协议层面的还是前端邮件客户端层面的，Stavros 明确指出这正是 SMTP 协议层本身，全都白纸黑字写在 RFC 中。 - **未加引号的双 `@`**：直接出现两个 `@` 符号显然是非法的。 - **引号内的特殊字符**：一旦 local-part 使用双引号包裹，此前违规的字符瞬间合法。不仅能在引号内放置 `@` 符号，甚至在引号内包含一个标准的 ASCII 32 空格（乃至 Unicode 字符）也是完全合法的。 - **引号的边界与点号分割**：当测试地址将引号与普通字符混合在一起时，观众再次跌入陷阱。Stavros 指出该地址非法的原因“并不是因为包含了 `@` 符号，而是因为引号部分必须用点号（`.`）进行分隔”。 - **转义与引号的反直觉规则**：当展示经过点号分隔、且引号内字符被反斜杠正确转义的地址时，该地址完全合法。Stavros 现场开玩笑承诺：“If you send email to this I will reply to you, I will literally do it.”（如果你往这个地址发信，我真会回复你，说到做到。） - **空格转义依然无效**：但紧接着展示试图仅通过反斜杠转义空格而不加双引号的地址时，答案依然是非法——RFC 规定空格即便转义，也必须被整体置于双引号中。 ```mermaid flowchart TD accTitle: 电子邮件 local-part 特殊字符合法性判断逻辑 accDescr: 展示特殊字符、空格、连续点号在加引号与未加引号状态下的不同合法性判定分支。 Start["输入 local-part 内容"] --> CheckQuotes{"是否被双引号包裹？"} subgraph Unquoted["未加引号分支"] CheckQuotes -->|否| UDot{"包含连续点号或开头/结尾点？"} UDot -->|是| UInvalid1["非法 (Invalid)"] UDot -->|否| USpace{"包含空格或未转义括号？"} USpace -->|是| UInvalid2["非法 (Invalid) 哪怕空格被转义也是非法"] USpace -->|否| USpec{"包含普通符号 (如 + * 等)？"} USpec -->|是| UValid1["合法 (Valid)"] end subgraph Quoted["引号包裹分支"] CheckQuotes -->|是| QDot{"引号与外部字符是否由点号分隔？"} QDot -->|否| QInvalid["非法 (Invalid) 引号必须由点号隔开"] QDot -->|是| QContent{"引号内包含空格、@ 或转义字符？"} QContent -->|是| QValid["合法 (Valid)"] end ``` --- ### [06:16](https://www.youtube.com/watch?v=xxX81WmXjPg&t=376s) 域名花样：IPv6、TLD 纯域名与十进制 IPv4 在 local-part 彻底击溃观众认知后，测试转向了 `@` 符号右侧的域名部分： - **IPv6 格式**：使用方括号包裹的标准 IPv6 主机名是合法的。 - **纯顶级域名（TLD）**：直接以单一顶级域名作为右侧主机名是合法的，因为顶级域名的邮件服务器确实能够接收邮件。 - **国际化与 Unicode 域名**：Unicode 字符在域名中完全有效。 - **数字 TLD**：纯数字串（如 `23456789`）作为顶级域名是非法的，因为它不是合法的已注册 TLD。Stavros 调侃道：“如果你肯去 ICANN 交上十万美元注册这个顶级域名，那它就合法了，到时候通知我改 PPT 就行。” - **十进制 IPv4 地址**：最后一道题是一个看似杂乱无章的长数字串，绝大多数观众以为是无效地址，但 Stavros 揭晓其完全合法——因为它是以**十进制整数形式表示的 IPv4 地址**。此前误判其为 IPv6 并猜错原因的听众，被 Stavros 再次打趣：“你们是基于完全错误的理由猜对的，应该感到更惭愧。” --- ### [07:23](https://www.youtube.com/watch?v=xxX81WmXjPg&t=443s) 终极解法：我们该如何验证邮箱？在展示了如此多荒谬、反直觉却完全合规的边界条件后，Stavros 总结指出，试图用严格的正则表达式或语法解析器去覆盖整个 RFC 5321 / RFC 5322 规范纯属徒劳。甚至连 RFC 规定“local-part 区分大小写”这一条，在现实现实世界中也几乎没有任何服务商在严格遵守。那么开发者究竟应该如何验证邮箱？Stavros 给出了一个无比极简却不可撼动的结论：不要去写天书般的正则表达式，只要检查字符串里有没有 `@` 符号即可。真正的验证只有一条路径：往该地址发送一封带有确认链接的邮件，等待用户点击。如果一个地址能收到信并被用户激活，它就是有效的。 Stavros 向台下所有开发者发出了半开玩笑的严厉警告：“If I see another signup form that says that my address is not valid I'm gonna hunt you down whoever it is and I'm gonna show you the presentation again.”（如果我再在哪个注册表单上看到提示说我的邮箱地址无效，不管你是谁，我都一定要把你揪出来，按着你把这个演讲再看一遍。） --- ### [08:04](https://www.youtube.com/watch?v=xxX81WmXjPg&t=484s) 问答环节：库推荐、加号误杀与安全性争议演讲结束后进入提问环节，观众就实际工程落地与技术细节展开了密集互动： - **Emoji 与新标准**：观众询问 Emoji 是否能放在邮箱中，Stavros 笑称加 Emoji 是在“作弊”，尽管这确实是个很酷的想法；面对邮件标准的演进，他坚称不论未来标准如何变迁，自己的简易法则（找 `@` 并发信）永远适用。 - **推荐的验证库**：有观众询问各种语言是否有优秀的邮件校验库。Stavros 的回答极为干脆：“Every language has an email validation library. It's usually you check like `if '@' in string`, that's it.”（每种语言都有邮件验证库，实现通常就是检查 `@ 是否在字符串中`，这就够了。） - **系统为什么搞得这么复杂？**：有观众感叹规范何以繁冗至此。Stavros 表示，想要跨越全球网络自由通信，就必须做出妥协，发送验证邮件并确认用户点击，是唯一没有副作用的途径。 - **加号（`+`）与长顶级域名的误杀**： - 观众提问为何现实中有大量网站粗暴地拒绝包含加号（`+`）的邮箱。Stavros 解释，纯粹是因为那些开发者缺乏经验，井底之蛙般以为邮件地址都长得千篇一律：“They think that they know better but they don't, because if they've seen like ten email addresses and they figure it is fine because they were all looking the same.”（他们自以为很懂，但其实根本不懂，就因为他们只见过十来个邮箱地址，长得都差不多，就以为全世界的邮箱都该那样。） - 另一位观众诉苦称自己的四位字母顶级域名频繁被网站报错。Stavros 幽默地表达哀悼，调侃道如果要是用五个字母的顶级域名，那基本在互联网上“就废了”，干脆注册个 Gmail 息事宁人算了。 - **极简规则的安全性与成本**：有听众担忧这种只查 `@` 符号就直接发信的机制是否会带来安全漏洞。Stavros 驳斥了这种观点，他强调这种方法反而是最安全的，因为它在判定有效性上具有“零误报、零漏报（no false positives and no false negatives）”的绝对确定性。尽管发信会有基础设施成本，但这就是“开展业务的必要代价（cost of doing business）”。 - **内网与非公开域名**：针对局域网内无法从公网解析的内部域名，Stavros 确认只要发信机器能够正确解析目标主机，该规则同样完美适配，证明仅校验 `@` 符号具有极强的普适性与鲁棒性。 ### [13:24](https://www.youtube.com/watch?v=xxX81WmXjPg&t=804s) 严格校验与简单规则的权衡：只要包含“@”就足够了吗？在问答环节伊始，一位现场观众提出了关于邮箱地址校验边界的疑问：RFC 规范中针对 local-part（本地部分）显然还有不少细则，那么去校验那些特定规则到底是不是纯粹浪费时间？开发者是应该直接采用“只要有一个 `@` 符号就判定合格”的极简策略，还是说这些规则本身也有一定的弹性空间？针对这一问题，Stavros Korokithakis 坦言这确实是个好问题。他指出，如果你百分之百确定某些格式必定非法，确实可以把它们拦截下来，以确保系统不会去尝试连接一个根本无法送达的地址；但在绝大多数现实场景中，最通用的策略其实就是只检查是否存在 `@` 符号。因为面对层出不穷的新顶级域名与复杂的网络环境，过度校验极易误伤合法用户，最稳妥的做法就是直接发一封验证邮件过去，看它能否送达。对于这一争论，Stavros Korokithakis 给出了非常干脆的总结：“I think them yeah the most general way to do it is just check for the add sign because you never know what kind of crazy new domains there will be and things like that so just send the email and be done with it.” 随后，另一位参会者就域名解析与主机迁移的不确定性进行了补充交流。面对各种复杂的校验机制，现场讨论了为何很多人偏要舍本逐末去设计各种繁琐规则。Stavros 开玩笑地自嘲道：“I don't know some people just calm presentations and spread misinformation.” - 针对非法格式的校验仅在开发者完全确信其不可达时才有意义，否则极易演变成过度设计。 - 面对不断演进的域名体系（如各类新型 TLD），繁复的本地正则匹配脆弱且难以维护，直接投递验证邮件才是真正的终极检验。 ### [14:43](https://www.youtube.com/watch?v=xxX81WmXjPg&t=883s) 奇葩边界案例探讨：带引号的“@”与域中的特殊字符问答环节随后进入了对各种古怪极端边界情况的探讨。有观众提出一个刁钻的语法漏洞：如果整个邮箱地址里唯一的 `@` 符号是包裹在双引号内部的（作为 local-part 的一部分，而没有分隔域名的未加引号的 `@` 符号），系统该如何处理？听到这个极端用例，Stavros 毫不客气地用幽默化解了这个荒谬的假设，引得全场哄堂大笑。他当场笑称：“then you don't deserve to be using the Internet and computers so yeah you're fine you deserve whatever you get a next question.” 换言之，任何故意写出这种地址的用户，遭遇任何系统错误都是自作自受。紧接着，另一位观众询问在 `@` 符号之后（即远端域名部分）是否允许紧跟惊叹号等特殊字符。Stavros 坦陈这种情况非常奇特，虽然传统规则下看似不可行，但考虑到国际化域名（IDN）和庞大的 Unicode 字符集，很多看起来像标点符号的东西实际上可能是某种语言中的合法字符。因此在现代网络环境下，永远不要把话说得太绝对。现场随即明确了该问题是在询问 remote part 中紧随 `@` 符号出现感叹号的情形。眼看各种钻牛角尖的极端案例层出不穷，台下逐渐安静下来，Stavros 见状调侃道：“it looks like everybody is happy with one simple rule great check for a bloody @ sign this is my this is my invalid email address and this is my my website you can see stuff there and if you want I'll be around.” 在全场的轻松气氛中，他展示了自己故意写错的“非法邮箱地址”和个人网站，正式结束了演讲。 ## Notable quotes > [13:24](https://www.youtube.com/watch?v=xxX81WmXjPg&t=804s) I think them yeah the most general way to do it is just check for the add sign because you never know what kind of crazy new domains there will be and things like that so just send the email and be done with it. — Stavros Korokithakis ## Mentioned Stavros Korokithakis, Larry, FOSDEM, RFC 5321, RFC 5322, Hotmail, AOL, Gmail, ICANN, SMTP ## Video description by Stavros Korokithakis At: FOSDEM 2018 Room: K.1.105 (La Fontaine) Scheduled start: 2018-02-04 16:30:00+01 [Source](https://www.youtube.com/watch?v=xxX81WmXjPg)

Source quotes

[13:24] Stavros Korokithakis: I think them yeah the most general way to do it is just check for the add sign because you never know what kind of crazy new domains there will be and things like that so just send the email and be done with it.

Original transcript

[0:06] next up is Stavros with a problem every [0:12] system and I am one has faced validating [0:16] email addresses so a big applause for a [0:19] short talk per Stavros thank you [0:21] Thank You Larry I'm stavos [0:24] my last name is unpronounceable in your [0:26] language sore won't bother I'm here to [0:29] speak about something that's very [0:30] important to me and I think this is the [0:32] most important talk in the conference [0:34] but yeah I also see many people here so [0:37] I'm afraid you have grossly [0:39] overestimated how useful this talk is [0:41] going to be but that's fine so I'm going [0:44] to talk about a new technology called [0:45] electronic mail it's an it's a it's a [0:48] product at well it's a technology that [0:49] lets you send letters to your pen pals [0:52] across the world instantly over the [0:56] internet how many how many of you have [0:59] an electronic mail account just raise [1:00] your hands maybe with you know hotmail [1:02] AOL okay so it's okay pretty popular is [1:04] he okay how many people have sent an [1:07] electronic mail to somebody or received [1:09] one okay that's fairly few people that's [1:12] good [1:13] how many people have a written software [1:15] that uses electronic mail all right [1:18] that's okay how many of you have written [1:20] software it has to pass an electronic [1:23] mail address and validate whether it's [1:24] correct or not okay you are all going to [1:27] need this talk so let me see if my [1:31] clicker works it doesn't work that's [1:33] fine I'm gonna do this by hand no this [1:37] doesn't work either what sorry yeah [1:41] electronic mail works presentations [1:43] doesn't okay so I'm going to show you [1:46] one address per slide and I want you to [1:48] shout whether it's valid or invalid just [1:51] like go up and shout and if you need any [1:52] clarification afterwards or something [1:54] just shout it's it's fine so this [1:58] address valid okay that is valid good so [2:02] you guys are off to a good start [2:04] how about this one then valid there is [2:07] no domain of course how about this one [2:10] is a plus there [2:12] okay that's good most of you have seen [2:14] it how about the dot they're valid okay [2:20] how about the dot there it is invalid if [2:25] you've said valid you need to come to me [2:28] for four classes for tutoring how about [2:32] two dots and volley that's Owen Valley I [2:36] can't have two dots in a row how about [2:37] this one it is invalid if you said valid [2:42] you should feel bad because you're [2:43] trying to be too clever but you weren't [2:45] how about this one there's an asterisk [2:47] and that bad word day is valid you can [2:52] have an asterisk in an auditorium we got [2:53] mail address how about this one [2:56] that is also valid because you can have [2:58] all these characters here there they're [3:00] fine how about this one are you sure do [3:09] you want to change your answer it is [3:14] invalid you cannot have parenthesis in [3:15] the email address how about this one [3:20] this is valid this is actually a comment [3:22] you can have a comments there this is [3:25] this is actually I have C compliant this [3:28] is standards compliant you can have a [3:29] comment there you can just put it it's [3:31] ignored by the mail server but you can [3:33] do it you can just you know put whatever [3:34] you want in there how about this one [3:39] this is also a comment and it's still [3:41] valid on your right who wrote this stuff [3:45] how about this it is invalid because you [3:50] have to add signs you can have to add [3:52] signs how about this [3:57] yes SMTP levels somebody has read the [4:11] IRC but yeah this isn't sorry yes that [4:13] question was whether this is SMTP level [4:15] or whether this was user facing mail [4:17] client stuff now this is SMTP this is in [4:19] the RFC so yeah if you said valid you [4:24] need to take a good look at yourself and [4:25] try not to be so clever this is a bunch [4:27] of illegal characters it does not have [4:29] anything how about this one oh that's [4:35] just and yeah this plays too short [4:37] it's supposed to be one-line valid or [4:39] invalid yeah who said valid go out again [4:44] it's just a bunch of characters how [4:46] about this one the two clever person was [4:51] actually correct this time because you [4:52] can have quoted at signs in the address [4:56] how about this one [4:58] with a space that is actually valid [5:02] because if you quote the space it's fine [5:05] yes [5:06] how about this one it's a it's a [5:12] standard ASCII 32 space so no yeah [5:16] Unicode will work as well but it yeah [5:18] anyway how about this one yeah this is [5:22] valid you quoted the space you can have [5:23] a space as you're a local part that's [5:25] fine how about now that is invalid and [5:31] not because of the out sign it's invalid [5:33] because the quotes must be dot separated [5:35] so if you have a quote you must [5:36] separated by dots how about this one and [5:42] now you didn't know because you have [5:43] poster posted a bunch of him and they [5:44] were invalid so is it invalid now is it [5:46] valid okay this is valid because we did [5:51] separate the quarter part and the cord [5:53] is escaped so yeah this is a yeah this [5:56] is if you send email to this I will [5:57] reply to you I will literally do it yeah [6:03] tricky one [6:04] we're escaping it but it's still a space [6:08] it's invalid because you have to set to [6:11] quote other spaces even if you escape [6:14] them how about this one [6:16] I see you guys know about our vv6 that's [6:21] a valid ipv6 host name how about this [6:24] one [6:27] okay okay that's good it's valid because [6:30] it's a TLD somebody at the TLT will take [6:32] it how about this one it is valid [6:37] because it's Unicode it's it's fine how [6:40] about this one it is invalid because two [6:46] three four five six seven eight nine is [6:48] not a domain so it doesn't it can get a [6:50] liver it's sorry it's not a TLD so yeah [6:54] if you go register the TLD and pay the [6:55] hundred thousand dollars you can get it [6:58] and I will just tell me to update my [7:00] slides though how about now confusing [7:07] but it's actually really fully valid [7:11] because it's a decimal ipv4 address it [7:14] was an ipv6 so it was correct for the [7:17] wrong reasons so you should feel even [7:18] more bad ok so since we kind of [7:23] demonstrated that you can tell by the [7:24] email address how do we validate and [7:26] keep in mind that the RFC is kind of a [7:29] recommendation at this point because the [7:33] RFC says that the local part is case [7:35] sensitive but nobody really does is case [7:37] sensitive so how do we validate an email [7:39] address we don't we just check if [7:42] there's an add sign in there and if [7:44] there is one we say ok you know passes [7:46] the first check you send an email to it [7:47] and then you wait for the user to click [7:49] the link or whatever so if I see another [7:51] signup form that says that my address is [7:53] not valid I'm gonna hunt you down [7:55] whoever it is and I'm gonna show you the [7:57] presentation again thank you very much [8:04] any questions I do not expect it yeah go [8:09] no no no I cannot put emojis because [8:12] that would be cheating next question [8:15] actually yeah that's a good idea robot [8:18] emojis though next question this is a [8:26] pretty new standard it's really going [8:28] like it's still under development sorry [8:30] the question was whether there are any [8:32] new developments [8:33] yeah it's changing over time but I think [8:35] you can be kind of sure that following [8:38] my advice wall will do yeah it will suit [8:41] you anybody else come on you must have [8:46] questions this is amazing technology yes [8:54] what library exists to check every [8:57] language has an email validation library [9:00] it's usually you check like if if at in [9:02] string that's that's that's it and every [9:06] every language will do it so you're [9:08] really lucky the they've all been [9:11] available next question oh so yes well [9:22] yes does it need to be so complicated is [9:24] the the question if you want an easy way [9:26] to to talk to all your pen pals wrote [9:29] the world it kind of like you have to [9:31] make some concessions you have to check [9:33] the address you have to send an email to [9:35] it you have to see if a user will click [9:38] the link there's really no easier way to [9:40] validate [9:49] oh yeah yes I will I will suggest that [9:54] to the elders of the Internet and maybe [9:56] they will take your suggestion thank you [9:59] next question is there an email talking [10:04] oh there okay except checking it in its [10:10] directly especially for forwarding well [10:14] I mean every mail server will validate [10:17] and kind of let you know like they will [10:19] send you a message back if the user [10:21] doesn't exist but yeah I don't know of [10:24] one that you can run as a service kind [10:26] of if that's what you're asking anybody [10:30] else do you have time do have time for [10:34] more questions I do have one why do so [10:40] many people reject if there's a plus [10:43] sign or whatever I mean everybody has [10:46] faith sir why do so many people do that [10:48] there's another motivation behind such [10:50] hurry well it's it's clearly [10:52] because I have not seen my presentation [10:54] but also yeah I mean that's it they they [10:57] think that they know better but they [10:59] don't because if they've seen like ten [11:02] email addresses and they're they figure [11:04] it is fine because they were all looking [11:05] the same but yeah they shouldn't they [11:07] should they should watch this anybody [11:10] else oh yeah [11:15] poor you yeah yet my condolences you [11:19] shouldn't have had a poor letter T [11:21] earlier than you Oh sir yes the question [11:24] was that this person has a for low level [11:27] a letter TLD and nobody accepts it which [11:30] is yeah if you have five level or five [11:32] letters you're just done you should get [11:33] a gmail one and be done with it next [11:37] question are there security risks [11:39] associated with allowing with your [11:41] simple rule no no actually my rule is [11:45] the most secure of all because you will [11:48] actually send an email and the user will [11:50] have to reply back and make sure that [11:52] they received the email before you can [11:54] consider them valid so it it actually [11:57] has no false positives and no false [11:59] negatives you were thinking of something [12:03] but you appear to be Trixie you can get [12:05] me later and we can discuss it yes and [12:12] it's going to be kind of costly to send [12:15] all these emails but again it's the cost [12:18] of doing business what are you gonna do [12:21] anybody else or a question yes [12:27] volunteers running do you have a link to [12:34] post when I want to put issue about [12:37] broken libraries that do it wrong yes [12:40] you can email me at any of these [12:41] addresses that you saw that the ones [12:43] that were valid and I will personally [12:44] reply to you and address the issue [12:47] there's another question there [13:01] yes yes so the question was whether the [13:04] email address can be valid if the domain [13:08] is basically not accessible from the [13:09] internet you mean yes yes that's fine [13:11] you can use your own internet servers [13:13] and it will work fine as long as the [13:15] machine can resolve the address you're [13:17] good so my rule again accepts this so [13:22] you can just check for the @ sign send [13:24] the email and we fine you see no [13:27] exceptions it's so hard to find a rule [13:29] like this so there seems to be a few [13:32] additional rules like it's a local part [13:35] would it just be a waste of time to [13:38] check for those as well so you use your [13:40] simple rule if there's a net it's good [13:42] enough or are they somehow flexible as [13:46] well actually that's a good yeah that's [13:48] a good question you can you can check [13:50] for the invalid ones if you're sure [13:52] they're invalid just to make sure that [13:54] the address cannot ever be reached but I [13:57] think them yeah the most general way to [13:59] do it is just check for the add sign [14:00] because you never know what kind of [14:02] crazy new domains there will be and [14:04] things like that so just send the email [14:05] and be done with it next question over [14:08] there yes behind the yeah so I'm not [14:18] sure that you know included just just in [14:23] case because you never know when the [14:24] host might move or whatever yeah exactly [14:31] exactly why would you be checking with [14:33] without and reason for the add sign I [14:35] don't know some people just calm [14:37] presentations and spread misinformation [14:39] next person sorry there's a few over [14:43] there but so what if you just have a [14:49] quoted at sign and that's the only one [14:51] then you don't deserve to be using the [14:54] Internet and computers so yeah you're [14:58] fine you deserve whatever you get a next [15:01] question [15:05] after that sign no because that's swell [15:08] hmm that's interesting I don't think so [15:11] but who knows what these new domains do [15:13] with their internationalized stuff maybe [15:16] it's not an actual quotation mark maybe [15:18] it's like a Russian something sign and [15:20] it's a valid Unicode domain so yeah [15:22] could be yes this was this was the old [15:38] form that was two days ago we changed it [15:40] oh sorry yes it was the question was [15:44] whether it's it's fine to have an [15:47] exclamation mark after the @ sign so for [15:49] the remote part next question it can be [15:56] the end come on somebody I it looks like [16:00] everybody is happy with one simple rule [16:03] great check for a bloody @ sign this is [16:11] my this is my invalid email address and [16:14] this is my my website you can see stuff [16:16] there and if you want I'll be around