EmailAddressExtractor

我被骗了吗电子邮件地址提取器

一个从给定路径中的任何文件中快速提取所有电子邮件地址的项目

背景

该项目旨在成为一个基本代码库的全新开源版本，我在十年的大部分时间里一直使用这个基本代码库，从数据泄露中提取电子邮件地址，然后将其加载到 HIBP 中。大多数违规行为都是 .sql 或 .csv 格式，位于单个文件或文件夹内的多个文件中，提取遵循一个简单的过程：

1. 通过正则表达式提取所有地址
2. 将它们转换为小写
3. 按字母顺序排列
4. 将它们保存到输出文件
5. 创建每个文件中有多少个唯一地址的报告

我使用的正则表达式如下： b[a-zA-Z0-9.-_+]+@[a-zA-Z0-9.-_]+.[a-zA-Z]+b

通过正则表达式进行电子邮件地址验证很困难，但它也不需要完美适合此用例。误报极其罕见，并且影响可以忽略不计，即非真实地址的字符串被加载到 HIBP 中，或者加载了不寻常格式的真实地址。在大多数情况下，这个正则表达式可以概括为“在 @ 符号的两侧填充字母字符的 TLD”。

实际考虑

在考虑解析规则时，讨论不可避免地会导致遵守 RFC 与某些字符的实际用途。这里有两个主要考虑因素：

1. 如果 RFC 允许使用双引号等字符，则应将其视为有效字符并允许在地址中使用
2. 双引号等字符更有可能是由于解析错误而不是合法使用而出现

有趣的是，与第 2 点相比，第 1 点很少是正确的。错误地拒绝合法的符合规范的地址的影响是它最终不会出现 HIBP（即低影响）。允许实际不存在的地址的影响是将垃圾记录引入 HIBP（影响也较低）。特别是当考虑实际使用具有模糊字符的地址的可能性时（例如，被接受到注册表中并且未被拒绝），总的来说，最好拒绝可能是解析错误的结果的字符。

1. 提取地址时

实际上，电子邮件地址中不太可能使用晦涩的模式

贡献

我已经联系并请求支持，并将通过一两个关键人物启动工作，然后寻求更广泛的意见。我对跨更大的数据集和非文本文件优化服务特别感兴趣，特别是随着勒索软件人员转储的文档不断增加。我将开始为需要构建的部分创建问题。

测试数据

使用 Red Gate 的 SQL 数据生成器，可以从 Mega 下载包含 10M 条典型违规数据记录的示例文件。此文件会导致使用此应用程序的当前版本提取 10M 电子邮件地址。注意：测试数据文件目前为V2，早期版本由于存在无效域名模式，导致唯一地址略少于10M。

运行地址提取器

语法： AddressExtractor.exe -?语法： AddressExtractor.exe -v语法： AddressExtractor.exe <input [[... input]]> [-o output] [-r report]

主要选项

选项	描述
-? , -h , --help	打印命令行语法和选项
-v , --version	打印应用程序版本号
输入	一个或多个输入文件名或目录
-o , --output输出	输出文件的路径和文件名。默认为“addresses_output.txt”
-r , --report报告	报告文件的路径和文件名。默认为“report.txt”
--recursive	为目录启用递归模式，这将搜索子目录
-y ， --yes	自动确认提示继续，无需询问
-q , --quiet	以更少的冗长运行，不显示进度消息

性能/调试

选项	描述
--debug	启用调试模式以进行微调性能检查
--threads数	使用带有通道的多个线程来读取文件。默认为4
--skip-exceptions	出现异常时自动提示CONTINUE