Problem/Motivation

A client is using webforms to submit applications for course enrolments. In this situation, the email field validation isn't tight enough because it allows email addresses that have a TLD only. The system to which applications are passed implements tighter checks so applications with this issue currently require manual intervention. Adding this option allows the case where a user enters "fred@gmail" as their address to be picked up at submission time, when they can correct it. The application can then progress without delay.

Steps to reproduce

Add an email field to a webform. In a test submission, try entering "fred@gmail" and see that it is accepted without issue. This isn't an issue with the Drupal service, which deliberately and correctly allows such addresses (https://www.drupal.org/project/drupal/issues/2822142), and this feature request should be an option for the same reasons.

Proposed resolution

I have prepared a patch that adds optional validation which requires a second level domain as well as a TLD.

Remaining tasks

Unit tests.

User interface changes

Adds a new 'Must be routable' option to the validation options for an Email address element.

API changes

Data model changes

Adds new properties for whether the check is made ('routable' - boolean) and the error message to be displayed if validation is executed and fails (routable_error - string, optionally including %mail).

Comments

NigelCunningham created an issue. See original summary.

megha_kundar’s picture

Status: Active » Needs review
jrockowitz’s picture

Status: Needs review » Needs work
Related issues: +#2864763: email_confirm element validate emails like 'user@domain'

This issue can be easily solved per element using a #pattern. I am not sure the webform should address this problem.

Should this issue be solved globally?

We could provide a code snippet (via a Recipe) that uses hook_element_info_alter() to add the email domain validation to all email elements. This snippet would be useful to everyone in the Drupal community because it would not be a webform specific solution.

jrockowitz’s picture

Status: Needs work » Closed (won't fix)

I think this issue should be fixed using a more general solution and global solution.

Someone just posted a great workaround, which could be moved into a dedicated contrib module.

@see https://www.drupal.org/project/drupal/issues/2822142#comment-13833560

nigelcunningham’s picture

Sorry for the delay in replying - not getting notifications for some reason.

The problem with using the global solution is it allows fred@localhost. The use case for my additional option is that there are cases where only routable addresses should be allowed.

jrockowitz’s picture

I think this should issue should be handled at a global level. Either a website's associated mail server can or can't handle routable addresses.

nigelcunningham’s picture

Hi Jacob.

Sorry if I'm not being clear enough in describing the use case. Let me try again.

A webform was created, allowing users of a website to complete an application to undertake study courses. One applicant accidentally only entered emailaddress@gmail. The address passed validation by Webform but was (rightly) rejected by the external API to which the application was then forwarded. This has led to the assertion that an email field should have the option to reject addresses that aren't routable - realising that there are other cases in which fred@localhost is perfectly fine.

Regards,

Nigel

jrockowitz’s picture

The solution provided by #2822142: Introduce a setting to make the top-level domain optional for email validation. will display an email validation error for fred@localhost.

nigelcunningham’s picture

Hi @jrockowitz.

The patch in the related issue isn't going to get applied to core. Would you reconsider applying this one, please?

jrockowitz’s picture

I think custom code or a dedicated contrib module is the better solution.

berdir’s picture

Your decision as a maintainer, but I do agree that this would be a very useful feature to have. We frequently have cases where users mistype their mails (e.g. write .c instead of .ch, or forget the TLD entirely, or use dashes instead of ., I've seen everything). That's problematic as you then can't notify them and we often also have issues with integrations in other systems like mailchimp which causes such a subscription to fail with an error.

As for the implementation, you could do ->isValid($mail, new DNSCheckValidation()) which does a full DNS check to make sure the e-mail domain is valid.

If you decide to reopen then we could look into writing some tests as well.

jrockowitz’s picture

Status: Closed (won't fix) » Needs work

Lets reopen this ticket.

paulocs’s picture

Status: Needs work » Needs review
StatusFileSize
new9.9 KB

Adding tests to it.
Cheers.

berdir’s picture

+++ b/tests/src/Functional/Element/WebformElementEmailTest.php
@@ -0,0 +1,43 @@
+    $this->assertRaw('A minimum second level domain is required.');
+
+    $edit = [
+      'email_no_routable_verification' => 'example01@example',
+      'email_with_routable_verification' => 'example02@example.com',
+    ];
+    $this->drupalPostForm('/webform/test_element_email', $edit, 'Submit');
+    $this->assertRaw("email_no_routable_verification: example01@example
+email_with_routable_verification: example02@example.com");

example.com specifically will actually not work anymore if you use the DNS verification thing as mentioned in my comment, because example.com does not have a MX record.

Whether or not we do use that approach, might make sense to use an e-mail address that would pass that check I think.

jrockowitz’s picture

The patch looks okay.

Personally similar to my thoughts from #7, I would want this to be a global configuration setting under /admin/structure/webform/config/elements. In one place, a site admin can decide how email addresses are validated.

jrockowitz’s picture

StatusFileSize
new1.66 KB

Attached is POC module that overrides the email.validator services and allows custom validation rules to be applied.

This approach to me makes the most sense since most sites would also like to validate user registration email addresses using the same logic.

This approach also validates email addresses entered via the admin UI.

Am I wrong to suggest that this should be handled via a dedicated contrib module?

@paulocs I really appreciate you taking a crack at the patch. While reviewing the patch, can't help but ask should this advanced email validation logic be a dedicated webform-only feature.

paulocs’s picture

Hey Jacob.
No problem. I see that patch #14 must have some improvements as pointed on comment #12 and #16 if we do a DNS verification.

About #17, it is a good idea to have this verification in a separate module because other people will be able to use the DNS verification regardless webform is installed or not.
But I don't know how other popular webforms handle this verification. If they provide this functionality in core I assume that webform module should have this functionality as well.

If you decide to create a another module for that, I can help anyway.
Let's see what other people will say.

Cheers.

jrockowitz’s picture

I don't have the bandwidth to create and maintain a new module. There are some similar modules available including https://www.drupal.org/project/email_validator

I agree that we need see what other people will say.

jrockowitz’s picture

Status: Needs review » Closed (won't fix)

I really this email address DNS validation enhancements should be done at a global level via #17. I am going to close this ticket.