Open imliam opened 4 years ago
It would be nice to make rules atomic and the package Universal.
unlimited-dots
plus-sign-tagging
minus-sign-tagging
(many system do this: user-something@example.com
)Then start constructor with domains + ->rules new UniqueEmailAddress(['gmail.com', 'googlemail.com'])->enableUnlimitedDots()->enablePlusSignTagging();
or rather new UniqueEmailAddress(['gmail.com', 'googlemail.com'])->removeSeparators('.')->removeTag('+');
A new rule could be mixed-case
And subdomain
Many domains have a wilcard in DNS: * IN MX mail.example.com
And idn-domain
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.
@imliam I think UniqueEmailAddress
should have these features.
[ $userPart, $domainPart ]
What are your use cases?
@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?
I cannot see value in regex-es, only hardship.
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.
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!
Gsuite offers the same kind of features to users with email addresses on custom domains. For example,
liam@liamhammett.com
andl.i.am+foobar@liamhammett.com
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