if you check this url email chacker with γγγγγ@address.com , this is
not valid email address ,
Thanks,
Ramin
--
Ticket URL: <https://code.djangoproject.com/ticket/27029>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* needs_better_patch: => 0
* resolution: => duplicate
* needs_tests: => 0
* needs_docs: => 0
Comment:
Sure thing!
Duplicate of #26423
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:1>
* status: closed => new
* has_patch: 0 => 1
* version: 1.10 => master
* resolution: duplicate =>
* stage: Unreviewed => Accepted
Comment:
Reopening as I have a patch which targets this specific issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:2>
Comment (by RaminFP):
Replying to [comment:2 claudep]:
> Reopening as I have a patch which targets this specific issue.
Hi,
Thanks a lot,
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:3>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:4>
Comment (by claudep):
I'm just wondering, is there still a use case to keep ASCII-only
validation (and hence provide `validate_email_ascii`)?
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:5>
Comment (by timgraham):
Not sure, maybe you want to ask on the DevelopersMailingList. I guess
usage might be a bit difficult until #25594 is fixed.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:6>
* stage: Ready for checkin => Accepted
Comment:
I just tested Firefox and Chrome email validation, and they don't accept
non-ASCII in the local part.
In any case, I think we should provide both validators (ASCII-only and
Unicode). It might be a bit too soon to unconditionally allow Unicode in
emails.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:7>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:8>
* type: Bug => Cleanup/optimization
Comment:
See #21859 for a documentation request to clarify the state of
ASCII/Unicode email addresses in Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:9>
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:10>
Comment (by RaminFP):
Hi Tim,
Please merge PR ,
Thanks
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:11>
Comment (by claudep):
Hey RaminFP,
I plan to come with a new patch, with two versions of the email validator.
I don't think that non-ASCII local parts of email addresses are widespread
enough to set it by default. The idea is that you could easily opt-in for
the Unicode validator of your choice when you define the field in your
models.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:12>
Comment (by RaminFP):
Replying to [comment:12 claudep]:
> Hey RaminFP,
> I plan to come with a new patch, with two versions of the email
validator. I don't think that non-ASCII local parts of email addresses are
widespread enough to set it by default. The idea is that you could easily
opt-in for the Unicode validator of your choice when you define the field
in your models.
Will be fix in new version 1.11? i can make suggestions to fix?
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:13>
Comment (by claudep):
Yes, the plan is clearly to include that in 1.11. We still have some
months ahead :-)
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:14>
Comment (by RaminFP):
Replying to [comment:14 claudep]:
> Yes, the plan is clearly to include that in 1.11. We still have some
months ahead :-)
Owesome, i have one question, you have
[https://github.com/django/django/blob/master/AUTHORS CONTRIBUTORS LIST] i
can add this list? or no i should try for send a lot of report for added
to list contributors?
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:15>
Comment (by claudep):
Yes, you are supposed to have done significant work for Django to be
listed there. Of course, that's very subjective, but filling a couple of
reports isn't sufficient for that.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:16>
Comment (by RaminFP):
Very good, i like working with Django community always in security and see
code issue for fix it,i see you write PR for this report so I can't add my
name to βCONTRIBUTORS LIST, :((
Thanks,
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:17>
Comment (by RaminFP):
Hi,
I see here way Contributing to Django
https://docs.djangoproject.com/en/dev/internals/contributing/
You write PR for patch issue ,this means my name not added?
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:18>
Comment (by timgraham):
Yes, we add to AUTHORS based on code contributions not bug reports.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:19>
* owner: Ramin Farajpour Cami => Wout De Puysseleir
* needs_better_patch: 1 => 0
* status: new => assigned
Comment:
[https://github.com/django/django/pull/7498 PR]
I've added a new patch for this.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:20>
* needs_better_patch: 0 => 1
Comment:
I am against this patch, adding more regular expressions is the wrong way
to go. I'd like to propose to change the current email validator to just
check if "@" is in the address and be done with it. See also
https://davidcel.is/posts/stop-validating-email-addresses-with-regex/ -- I
think this is something which should have a bit of discussion on the
mailing list.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:21>
* cc: Florian Apolloner (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:22>
Comment (by Tim Graham):
Ideas about simplification are discussed in #26423 and
[https://groups.google.com/d/topic/django-
developers/ASBJ0ge2KYo/discussion on the django-developers mailing list].
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:23>
Comment (by Collin Anderson):
if we do allow non-ascii, I wonder if we should be sure the email is
"printable" (not allow hidden characters like '\u200b')
https://docs.python.org/3/library/stdtypes.html#str.isprintable
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:24>
* owner: Wout De Puysseleir => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:25>
Comment (by j-bernard):
Commenting here since #33967 has been closed as a duplicate.
Unicode in local-part is allowed by the latest standards, therefore
`EmailValidator` is preventing valid email addresses to be used in Django.
Making the current regex allow Unicode characters instead of `[0-9A-Z]`
would do the trick.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:26>
Comment (by j-bernard):
I submitted this [https://github.com/django/django/pull/16181 PR]. I made
it change as little as possible to at least get Unicode local-part valid.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:27>
* needs_better_patch: 1 => 0
Comment:
Improvement flag was set on prior PR proposing additional regular
expressions. Current [https://github.com/django/django/pull/16181 PR]
simplifies the existing one per
[https://code.djangoproject.com/ticket/27029#comment:26 comment].
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:28>
* owner: (none) => j-bernard
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:29>
Comment (by Carlton Gibson):
The new PR seems ''OKβ’'' βΒ for
[https://docs.python.org/3.11/library/re.html#index-34 strings `\w`] is
equivalent to `[a-zA-Z0-9_]` with ASCII, and the unicode examples then
pass.
I worry slightly about bringing in a host of lookalike address
vulnerabilities. π€
I think this needs a discussion to decide the way forward.
1. I'm not convinced this is really a distinct issue to #26423.
2. [The https://groups.google.com/d/topic/django-
developers/ASBJ0ge2KYo/discussion mailing list discussion] was essentially
unanimous to radically simplify here (rather than continue to tweak).
Florian's comment:21 more or less sums it up:
> ...propose to change the current email validator to just check if "@" is
in the address and be done with it.
We've said similar with URLValidator a number of times.
I'm not sure we shouldn't (again) mark this as a duplicate of #26423, re-
purpose that to simplify the validation, make sure ''How to customise
validation'' shows the way forward clearly, and then close everything else
in this area as `wontfix`. π€
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:30>
Comment (by Claude Paroz):
Different projects have different requirements. What about providing
different validators: a simple one where only `<somechar>`@`<somechar>`
presence is checked, a more elaborate one like the current one, and an
equivalent to the previous allowing unicode. The question then is to
decide which would be the default.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:31>
Comment (by Carlton Gibson):
I think that sounds quite reasonable Claude.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:32>
Comment (by j-bernard):
Here is a little context for my use case. In general, I create my own
validator whenever it's needed to override the default Django behavior but
I have a particular case where django-allauth app is used and is using the
EmailValidator. In that case, I cannot easily override it.
My suggestion would then be to make the default validator more permissive
to get some flexibility in the kind of use case that I have. One can still
include another validation layer on top of that.
If you don't mind implementing a more complex specific validator for
internationalized email addresses it would be better to avoid using only a
regex. I kept it the simplest as I could in my PR because I'm aware that
changing the validator is touchy.
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:33>
* needs_better_patch: 0 => 1
Comment:
> My suggestion would then be to make the default validator more
permissive to get some flexibility in the kind of use case that I have.
One can still include another validation layer on top of that.
I don't think we can just swap out the current validation for a looser
one. Folks will be depending on the existing behaviour.
Maybe we can ship a couple of variants, but I'm not sure what switching
method we might allow. I think we need a story there in order to proceed.
π€
I looked at `django-allauth` β it's using the `validate_email` instance,
in various, deeply-nested places β I think an issue over there, to look at
making that pluggable, is needed really. (In the meantime, one could
monkey patch `validate_email` with whatever validator you wanted to adjust
thatβ¦ β again, not something I think we can just swap out from beneath
it.)
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:34>
* cc: Carlos Palol (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:35>
* cc: Collin Anderson (added)
Old description:
> {{{
> from django.core.validators import validate_email
> validate_email('γγγγγ@email.com')
> }}}
>
> if you check this url email chacker with γγγγγ@address.com , this is
> not valid email address ,
>
> Thanks,
> Ramin
New description:
{{{
from django.core.validators import validate_email
validate_email('γγγγγ@email.com')
}}}
if you check this url email chacker with γγγγγ@address.com , this is
not valid email address ,
Thanks,
Ramin
--
Comment:
I'm just noticing today that unicode.org has recommendations on email
security:
https://www.unicode.org/reports/tr39/#Email_Security_Profiles
- It must be in NFKC format
- It must have level = <restriction level> or less, from
`Restriction_Level_Detection`
- It must not have mixed number systems according to
`Mixed_Number_Detection`
- It must satisfy dot-atom-text from RFC 5322 Β§3.2.3, where atext is
extended as follows:
- Where C β€ U+007F, C is defined as in Β§3.2.3. (That is, C β
[!#-'*+\-/-9=?A-Z\^-~]. This list copies what is already in Β§3.2.3, and
follows HTML5 for ASCII.)
- Where C > U+007F, both of the following conditions are true:
- C has `Identifier_Status=Allowed` from General Security Profile
- If C is the first character, it must be `XID_Start` from Default
Identifier_Syntax in [UAX31]
It doesn't recommend which "restriction level" to use, and maybe we should
allow the user to decide what level to use (defaulting to 1: ASCII-Only).
(Also, it would be nice if Python implemented "Mixed-Script Detection",
"Restriction-Level Detection" and "Mixed-Number Detection" as part of
unicodedata.)
--
Ticket URL: <https://code.djangoproject.com/ticket/27029#comment:36>