Add support for Gsuite domains

[imliam]

Gsuite offers the same kind of features to users with email addresses on custom domains. For example, [email protected] and [email protected] both go to the same inbox.

PHP provides a handful of functions like getmxrr() that could be used to check if a domain has MX records pointing to Google, denoting that it's using Gsuite.

https://www.php.net/manual/en/function.getmxrr.php

getmxrr('liamhammett.com', $hosts);

$hosts === [
    'alt1.aspmx.l.google.com',
    'alt2.aspmx.l.google.com',
    'alt3.aspmx.l.google.com',
    'alt4.aspmx.l.google.com',
    'aspmx.l.google.com',
];

[szepeviktor]

It would be nice to make rules atomic and the package Universal.

• unlimited-dots
• plus-sign-tagging
• minus-sign-tagging (many system do this: [email protected])

Then start constructor with domains + ->rules ~~new UniqueEmailAddress(['gmail.com', 'googlemail.com'])->enableUnlimitedDots()->enablePlusSignTagging();~~

or rather new UniqueEmailAddress(['gmail.com', 'googlemail.com'])->removeSeparators('.')->removeTag('+');

[szepeviktor]

A new rule could be mixed-case

• [email protected]
• [email protected]

[szepeviktor]

And subdomain

• [email protected]
• [email protected]

Many domains have a wilcard in DNS: * IN MX mail.example.com

[szepeviktor]

And idn-domain

• [email protected]
• user@examplé.com

[imliam]

I'd be absolutely on board with such a change. I heard something about hey.com introducing similar rules on its emails, so this kind of rule-based change would make supporting additional services like that much easier.

It'd practically be a rewrite of the package though. I guess each rule could have its own class that accepts the email address with a normalize and regex method that can be used to perform the actions needed for each rule.

[szepeviktor]

@imliam I think UniqueEmailAddress should have these features.

• be extendable (with an example in the README)
• 100% flexible configuration (thus no magic strings or numbers in the source code)
• tell whether a valid email address belongs to the configured domains
• normalize an address, maybe return [ $userPart, $domainPart ]
• compare two addresses
• and Nothing else

What are your use cases?

[imliam]

@szepeviktor my own case is pretty much handled by the package in its current state; normalising against dots, tags and domain does what I need it to.

I've taken a quick first stab at splitting up the rules in #4 if you want to take a look and go from there?

[szepeviktor]

I cannot see value in regex-es, only hardship.

[imliam]

The reason I decided to go with regular expressions is because it's flexible enough to use in various different environments and points in an application; eg. giving the regex to the frontend to match against, giving it to an SQL query to assert against the database, etc.

I don't really see any better solution than regex - in my case I don't want to store the normalised versions of email addresses in a database, I want the original one the user entered - so it's not as simple as doing a direct equality comparison.

[szepeviktor]

in my case I don't want to store the normalised versions of email addresses in a database

I suspected the regular expression will travel a long way between languages. Why have this package when a single preg_match() can do everything? Get cleaned up local part, add @gmail.com, Done!