email-parse
email-parse copied to clipboard
mmucklo
Email\Parse is a multiple (and single) email address parser for php that is reasonably RFC822 / RFC2822 compliant.
It looks that the underlying `zendframework/zend-validator` package is using the `container-interop/container-interop` package which is now deprecated. The zend validatior package is also now abandoned https://github.com/zendframework/zend-validator ``` mmucklo/email-parse 2.0.0 email-parse a...
``` $sendingAddress = "Example | Example "; $result = \Email\Parse::getInstance()->parse($sendingAddress, false); $sendingDomain = strtolower($result['domain']); print '$sendingDomain = ' . $sendingDomain; $sendingAddress = strtolower($result['local_part']) . '@' . $sendingDomain; print ': $sendingAddress...
not sure why this is an invalid email ``` Dogster dogster_351A7140D2F608917B168757AC6E2E47911F5D180AD881092669F00B7081D5F5@reply.dogster.com ``` This is coming directly from an email header. Is it the code or is it indeed invalid?
Update dependencies to support PHP >=7.1 and remove the composer.lock file which shouldn't be checked in. Also update PHPUnit, and other packages that are depended upon.
It would be great if the parser showed comments as a specific attribute, see https://tools.ietf.org/html/rfc5322#section-3.2.2 Informal example: comments are allowed with parentheses at either end of the local-part; e.g. john.smith(comment)@example.com...
According to RFC822 this is a valid email address
`[email protected]; [email protected]` doesn't seem to be parsed here. can you add support? also reported in zend-mail: https://github.com/zendframework/zend-mail/pull/147
Right now scrutinizer is reporting 72% code coverage. It would be good to increase that to above 90%
It would be good to do a little refactoring to improve our scrutinizer rating. One concern of mine is if I modularize things too much that the performance of the...
