Add support for a user-configurable whitelist, preferably by email user domain. The whitelist in my view would continue to check email addresses for correct user/host pairs, but would NOT perform the more advanced username and HELO/MAIL FROM/RCPT TO checks.

The reason (at least in my case) is this - when using shared hosting or cloud servers, your server is going to be in a range with other cloud servers. Sometimes those servers are added to a blacklist by mail service providers. When you connect, they reject the mail connection outright. However, the email is a valid email address. And in my case, I use an upstream mail provider to send emails, so any email that is actually destined for the user would arrive properly.

What this means is:

Drupal machine -> Remote mail server = rejected (email_verify fails the check - which in my case means their requested invite is rejected.)
Drupal machine -> Mail service provider -> Remote mail server = accepted, so email to them actually works properly

The net result is a failed check when it really shouldn't have failed.

#4 1435158-04.patch2.34 KBrjbrown99


Taps7734’s picture

This would be a great addition. And if I knew anything about PHP, I would patch it already.

On the other hand, I know there was a discussion of a BLACKlist, but it was determined that it would be more productive to use the built in rules in admin/user/rules to deny email addresses. Would it not be more prudent to go with this same theory for the whitelist? If an address is determined to be allowed, then the verify module could override the check and allow it anyways.

Again, not knowing much about PHP, I can only speculate. But how hard would it be to add a quick check to user_admin_access_check_submit to see if the addresses were in the ALLOW list before email_verify made its decision?

Taps7734’s picture

OK.... so not knowing WTF I am doing... I have given this a try....

I have added a bit here... and I cannot figure out why it isnt working:

In, right after the "_email_verify_check", I added

  if (email_access_allow_check($mail)) {
    return t('$mail is whitelisted.');

The line that shows email address and text is just for testing right now. I just want it to verify that it does actually see the address as whitelisted. When it works, then I will just have it return with no text and move on to the next one.

In email_verify.module , right under the "function email_verify_help" section, I added

function email_access_allow_check($mail) {
	$sql = "SELECT 1 FROM {access} WHERE type = 'mail' AND LOWER('$mail') LIKE LOWER(mask) AND status = 1";
	return db_result($sql);

I have tested the SQL string using PHPMyAdmin and it returns a "1" like I would expect. But when I attempt to open admin/user/user/email_verify , it doesnt show any of the addressed I expect to be there. I know for a fact that there are addresses that I have allowed, I put them in there just to test this.

Any reason why I cannot get this to work? I realize it is probably something very simple that I am doing wrong. I just dont know what it is.

rjbrown99’s picture

I implemented this - let me see if I can roll up a patch.

rjbrown99’s picture

2.34 KB

Here it is. It adds a new administration page for "Email Verify" where you add domains to ignore. It must be a full domain per line, no wildcard or partial matching. IE, works but * is not going to work.

rjbrown99’s picture

Status: Active » Needs review

On another note - if the existing maintainers aren't around and would like a bit of help committing this and a few of the other patches in the queue, feel free to add me as a maintainer. I'm using this module and will continue to do so. I can't provide ongoing Q&A in the issue queue, but I can certainly review and apply patches that come up, fix some of the coding standards reported by the coder module, etc.

Taps7734’s picture

Status: Needs review » Active

OK... I got this to work, but it isn't pretty.

In I added

function _email_verify_check($mail) {
  if (!valid_email_address($mail)) {
    // The address is syntactically incorrect.
    // The problem will be caught by the 'user' module anyway, so we avoid
    // duplicating the error reporting here, just return.
	// Checks ACCESS for allowed email addresses.  If true, bypasses anyother checks.
  if (email_access_allow_check($mail)) {
    //return t('%mail is whitelisted.', array('%mail' => "$mail"));

  // checkdnsrr and getmxrr were added to Windows platform in PHP 5.3 

In email_verify.module I added:

function email_verify_help($path, $arg) {
  if ($path == 'admin/help#email_verify') {
    $txt = 'This module verifies that email addresses are valid during account registration or edit.';
    return '<p>'. t($txt) .'</p>';

 * Hacked Whitelist of sorts
function email_access_allow_check($mail) {
	$sql = "SELECT 1 FROM access WHERE type = 'mail' AND LOWER('$mail') LIKE LOWER(mask) AND status = 1";
	$result = db_query($sql);
	if (db_affected_rows($result) > 0)
	{$allow = 1;}
	{$allow = 0;}
    return $allow;

 * Implementation of hook_user().

I am sure that can be done a little cleaner. If someone wants to clean it up and put it in PATCH format, go for it. In the code above, I left the existing code and comments from before and after what I changed, so you could see where I put it.

But in the end, I have it checking the email address entered against the ACCESS tables allowed mail entries. If it finds a match, it skips the rest of the checks.

Taps7734’s picture

OK... so I never refreshed the page after I posted my first bit of failed code. So I didnt see the other responses.

While I do think the option in #4 is a possibility, I dont see why the need for a duplicate list is necessary. I'm not saying it is wrong. I am saying I dont know what I am doing and would like to have it explained to me. Wouldn't it be a better idea to use an existing function in drupal to handle the whitelists?

rjbrown99’s picture

#4 is very simple. There is a textarea on a configuration page that saves a list of domains to a variable. One domain per line.

At runtime, during the email_verify process it checks for that variable. If it exists, it builds an array of the whitelisted domains. If the domain to be checked is in the array, it just returns which allows the rest of the process to continue. If the domain is not in the whitelist, the remainder of the email_verify checks are performed.

I'll give you an example of my use case.

1) User attempts to register for our Drupal site.
2) Email verification module fires up, tries to validate the address.
3) During the SMTP server check, the email_verify module connects to the remote site's SMTP server. In this case, the remote site sent back a connection error. The remote site in this case does not like the fact that our Drupal server is hosted at Amazon, and they have elected to block all inbound mail requests from Amazon. So the end result was the user could not register for our site because email_verify issues an error.

With this patch, I can now add the user's domain to our whitelist. In this case, prior to running the SMTP checks the whitelist check takes place. If the domain is on the whitelist, we bypass the SMTP and other checks. This stops the address failure and allows the user to register for the site.

I am not using the Drupal user module's access table for one reason: in this case I just want the email address to be verified properly and allow the remainder of the process to proceed normally. If I was to use the access table and start adding domain whitelists there, it may have additional unintended consequences. The access table controls both ability to register as well as log in. I don't want to whitelist a domain in the access table (such as a widely used domain like, end up wanting to deny site access to one user of that domain, but not be able to do it because it would break email verification. I wanted my feature to be self-contained and only apply to bypassing email_verify checks.

rjbrown99’s picture

Status: Active » Needs review
rjbrown99’s picture

This has been committed to my email_verify fork here:

oadaeh’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)

Due to Drupal 6's EOL, I am closing this with "won't fix." If you feel this is still valid for any of the 7.x branches, feel free to re-open and update this issue.