But in reality, Django doesn't actually care :
https://code.djangoproject.com/ticket/31959#ticket
It would be only fair to users to document that the EmailValidator will
let invalid emails through, which will be the cause of SMTPError, and that
people who don't want invalid emails in their EmailField must override and
fix Django's default behaviour.
--
Ticket URL: <https://code.djangoproject.com/ticket/31960>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Old description:
> Currently, Django makes it seem that using an EmailField / EmailValidator
> will protect projects from getting invalid emails in their database, for
> example: emails starting with a dot like ".f...@bar.com" will be invalid
> as expected.
>
> But in reality, Django doesn't actually care :
> https://code.djangoproject.com/ticket/31959#ticket
>
> It would be only fair to users to document that the EmailValidator will
> let invalid emails through, which will be the cause of SMTPError, and
> that people who don't want invalid emails in their EmailField must
> override and fix Django's default behaviour.
New description:
Currently, Django makes it seem that using an EmailField / EmailValidator
will protect projects from getting invalid emails in their database, for
example: emails starting with a dot like ".f...@bar.com" will be invalid as
expected.
But in reality, Django doesn't actually care :
https://code.djangoproject.com/ticket/31959#ticket
This makes the following documentation statement inaccurate:
> "EmailField: A CharField that checks that the value is a valid email
address using EmailValidator."
Source :
https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield
It would be only fair to users to document that the EmailValidator will
let invalid emails through, which will be the cause of SMTPError, and that
people who don't want invalid emails in their EmailField must override and
fix Django's default behaviour.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/31960#comment:1>
Old description:
> Currently, Django makes it seem that using an EmailField / EmailValidator
> will protect projects from getting invalid emails in their database, for
> example: emails starting with a dot like ".f...@bar.com" will be invalid
> as expected.
>
> But in reality, Django doesn't actually care :
> https://code.djangoproject.com/ticket/31959#ticket
>
> This makes the following documentation statement inaccurate:
>
> > "EmailField: A CharField that checks that the value is a valid email
> address using EmailValidator."
>
> Source :
> https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield
>
> It would be only fair to users to document that the EmailValidator will
> let invalid emails through, which will be the cause of SMTPError, and
> that people who don't want invalid emails in their EmailField must
> override and fix Django's default behaviour.
New description:
Currently, Django makes it seem that using an EmailField / EmailValidator
will protect projects from getting invalid emails in their database, for
example: emails starting with a dot like ".f...@bar.com" will be invalid as
expected.
But in reality, users must not count on Django for that:
- https://code.djangoproject.com/ticket/31959
- https://code.djangoproject.com/ticket/25452
This makes the following documentation statement inaccurate:
> "EmailField: A CharField that checks that the value is a valid email
address using EmailValidator."
Source :
https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield
It would be only fair to users to document that the EmailValidator will
let invalid emails through, which will be the cause of SMTPError, and that
people who don't want invalid emails in their EmailField must override and
fix Django's default behaviour.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/31960#comment:2>
Old description:
> Currently, Django makes it seem that using an EmailField / EmailValidator
> will protect projects from getting invalid emails in their database, for
> example: emails starting with a dot like ".f...@bar.com" will be invalid
> as expected.
>
> But in reality, users must not count on Django for that:
>
> - https://code.djangoproject.com/ticket/31959
> - https://code.djangoproject.com/ticket/25452
>
> This makes the following documentation statement inaccurate:
>
> > "EmailField: A CharField that checks that the value is a valid email
> address using EmailValidator."
>
> Source :
> https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield
>
> It would be only fair to users to document that the EmailValidator will
> let invalid emails through, which will be the cause of SMTPError, and
> that people who don't want invalid emails in their EmailField must
> override and fix Django's default behaviour.
New description:
Currently, Django makes it seem that using an EmailField / EmailValidator
will protect projects from getting invalid emails in their database.
But in reality, users must not count on Django for that:
This makes the following documentation statement inaccurate:
> "EmailField: A CharField that checks that the value is a valid email
address using EmailValidator."
Source :
https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield
It would be only fair to users to document that the EmailValidator will
let invalid emails through, which will be the cause of SMTPError, and that
people who don't want invalid emails in their EmailField must override and
fix Django's default behaviour.
As to why EmailValidator would reject emails starting with a dot like
".f...@bar.com" but not emails starting with a hyphen "-f...@bar.com": this
will remain a mystery.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/31960#comment:3>
* status: new => closed
* resolution: => wontfix
--
Ticket URL: <https://code.djangoproject.com/ticket/31960#comment:4>
Comment (by James Pic):
Actually I think there is nothing we can do really, even SMTP VRFY is not
going to be reliable because some providers block it "to foil spammers":
https://docs.python.org/3/library/smtplib.html#smtplib.SMTP.verify
--
Ticket URL: <https://code.djangoproject.com/ticket/31960#comment:5>