JoshData / JoshData/python-email-validator

Version 2.3 breaks a ton of pydantic models and rules

Open
#160 8 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1.4k
Forks
140
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Start by reviewing the version 2.3 change against the cited RFC 5321 limits and the reported Pydantic-model regressions; done requires an explicit decision on compatibility defaults and strict local-part validation.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.