JoshData / JoshData/python-email-validator
Version 2.3 breaks a ton of pydantic models and rules
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 1.4k
- フォーク
- 140
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
This decision will result into a nightmare:
• The library no longer checks that the local part is at most 64 characters because a more careful reading of RFC 5321 indicates the limit is optional and such email addresses have been found in the wild. However the check can be restored using a new strict=True parameter, and the overall 254 character email address length limit is still in place.
All the articles I found on the Internet specifies: 64 before @ and 255 after, with an overall size limited to 254.
Refering to RFC 5321, it reads:
4.5.3.1. Size Limits and Minimums
There are several objects that have required minimum/maximum sizes.
Every implementation MUST be able to receive objects of at least
these sizes. Objects larger than these sizes SHOULD be avoided when
possible. However, some Internet mail constructs such as encoded
X.400 addresses (RFC 2156 [35]) will often require larger objects.
Clients MAY attempt to transmit these, but MUST be prepared for a
server to reject them if they cannot be handled by it. To the
maximum extent possible, implementation techniques that impose no
limits on the length of these objects should be used.
Extensions to SMTP may involve the use of characters that occupy more
than a single octet each. This section therefore specifies lengths
in octets where absolute lengths, rather than character counts, are
intended.
4.5.3.1.1. Local-part
The maximum total length of a user name or other local-part is 64
octets.
4.5.3.1.2. Domain
The maximum total length of a domain name or number is 255 octets.
I do not see any hint about optional.
Also, as a backward compatibility, it would have been better to make the strict parameter a lazy or compat parameter which defaults to True and not False....
Please advice.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
この issue ではファイル、テスト、エントリポイントが指定されていません。まず、RFC 5321 の引用された制限および報告された Pydantic-model のリグレッションに照らして version 2.3 の変更を確認してください。完了には、互換性のデフォルトと local-part の厳密なバリデーションについて明示的に決定することが必要です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- backend
- issue の種類
- バグ
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100