Code

Opened 8 years ago

Closed 7 years ago

#3138 closed enhancement (wontfix)

isValidEmail accepts non-wellformed e-mail address. SMTP 'VRFY' and MX/A DNS lookup provides better validation.

Reported by: mpjung@… Owned by: adrian
Component: Validators Version:
Severity: normal Keywords: email validator smtp vrfy
Cc: mpjung@…, mir@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Currently the E-Mail-Validator only checks for well formed e-mail addresses via a very simplified regular expression. This recently gave me troubles as an address with leading '-' was allowed. foo@… was validated correctly, but threw an error later when trying to send an e-mail using this address.

The Book “Mastering Regular Expressions” by Jeffrey E. F. Friedl comes with a very advanced regular expression (filling a complete A4 page if printed with a readable font) and quickly shows that the approach of a simple pattern match is not too great for validating e-mail addresses.

I have been looking at the SMTP RFC and found the command "vrfy" which allows the user to check if a specific e-mail address would be accepted as recipient. The python smtplib also supports this feature via the verify method so it would be quite easy to implement a validator that uses the default SMTP server to check for validness of entered e-mail addresses.

I would like to add a configuration variable called VALIDATE_EMAIL_ADDRESS_VIA_SMTP (better name?) which can be set to True if e-mail validation should be done via the configured SMTP host.

Attachments (2)

dns_check.py (6.3 KB) - added by Michael Radziej <mir@…> 8 years ago.
demo code for a DNS resolving validator
dns_check.2.py (6.7 KB) - added by Michael Radziej <mir@…> 8 years ago.
... adding stuff I forgot before …

Download all attachments as: .zip

Change History (8)

comment:1 Changed 8 years ago by mir@…

  • Cc mir@… added

Are you talking about the localpart of the email address or the domain part?

Within the localpart, a leading '-' IS an allowed localpart for an email address.

Within the domain part, I think you're right, but haven't found a reference within the standard RFCs that forbids it. You don't have one, by chance?

Django seems to check domains a little bit too relaxed and accepts a leading "-" in domain parts all over the place (also for URLs etc.) You'll never be sure that an email can be sent to unless you have tried. I don't know if it's really worth to check exactly for what is allowed. It's much more important that the validators don't falsely claim something to be wrong that isn't.

VRFY won't help since you don't want to stop your http processing to contact a possibly slow mail server. And VRFY is not widely implemented.

comment:2 Changed 8 years ago by mpjung@…

  • Summary changed from isEmailValid accepts non-wellformed e-mail address. Remote validation via SMTP 'vrfy' could save a lot of trouble. to isValidEmail accepts non-wellformed e-mail address. SMTP 'VRFY' and MX/A DNS lookup provides better validation.

I am talking about the domain part of the e-mail address. “foo@…” is reported as valid e-mail address by the isValidEmail validator.

The VRFY command works in my case as the MX is the same machine which has only little load. I guess on a large scale website validation via SMTP VRFY could cause some troubles, but in my case it would be the solution causing the best result with the least effort. As MTA I am using Postfix which seams to implement VRFY correctly.

An alternative and addition to SMTP VRFY would be a MX/A record lookup for domain part. That way e-mail addresses for non-existing domains would be rejected, too. Even though it's not guaranteed that the SMTP server doesn't reject the recipient address later. e.g. think of a local delivery and the recipient address doesn't exist. Even though a VRFY during validation time doesn't guarantee that the email will be sent successfully it will at least minimize the chance.

I would go for an optional A/MX lookup and an optional VRFY check – both to be configured in the settings.py.

comment:3 Changed 8 years ago by Michael Radziej <mir@…>

I have developed a DNS-resolving validator for my own use, so I've attached it. Read the docstring and adapt to your needs ;-)

I don't use it as validator but only to give warnings. DNS sometimes just takes 1 second longer than your timeout, no matter what it is.

Changed 8 years ago by Michael Radziej <mir@…>

demo code for a DNS resolving validator

Changed 8 years ago by Michael Radziej <mir@…>

... adding stuff I forgot before ...

comment:4 Changed 8 years ago by adrian

  • Component changed from django.core.mail to Validators

comment:5 Changed 7 years ago by Michael Radziej <mir@…>

  • Triage Stage changed from Unreviewed to Design decision needed

comment:6 Changed 7 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to closed

We cannot use VRFY, since it is usually turned off for privacy and spam reasons.

I think Michael's validator is probably something to put in the wiki and point people to who want something more than the simple regular expression and who are willing to wait for the DNS lookup (which can be slow and, as Michael points out, fail temporarily). We are just trying to catch the most fundamental errors with the reg-exp. If you really want to verify that an email address is correct, send them an email and require a reply.

No core additions needed here, for those reasons.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.