genkgo/mail

Parsing addresses

EmielBruijntjes opened this issue · 8 comments

Hello Frederik,

The existing PHP mail libraries are not good, so I can see the point of writing a new one. But I took the liberty to run some test input that we use for our software through your library, and you might want to spend some extra time on it. Parsing email addresses is painful, especially if you want to be fully RFC 2822 compatible. I can give you some extra input once you have tackled this :)

Cheers,

Emiel

<?php

require_once __DIR__ . "/src/EmailAddress.php";

try
{
    $address = new Genkgo\Mail\EmailAddress('"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com');

    echo("localpart: ".$address->getLocalPart()."\n");
    echo("domain: ".$address->getDomain()."\n");

}
catch (Exception $exception)
{
    echo("valid address not recognized\n");
}

$address1 = new Genkgo\Mail\EmailAddress("address(withcomment)@example.com");
$address2 = new Genkgo\Mail\EmailAddress("address@example.com");

echo("localpart 1: ".$address1->getLocalPart()."\n");
echo("domain 1: ".$address1->getDomain()."\n");
echo("localpart 2: ".$address2->getLocalPart()."\n");
echo("domain 2: ".$address2->getDomain()."\n");

// we expect the addresses to be similar, because comments should be ignored
if ($address1->equals($address2)) echo("yes they are equal!\n");
else echo("two identical addresses are not considered equal\n");

Hi Emile,

Thanks a lot for the feedback. Because I wanted to get this baby out of the door after two weeks of hard work, I choose to focus on a stable API. Hence, I decided to be liberate in the values to accept as email address.

Now the API is stable, a RFC compliant e-mail address parser is an area that will have focus now. I have already read upon some difficulties that I might hit in this regard. Therefore I already skipped regular expressions, and implemented a byte per byte parser. But yes, it will not be a funny exercise to get it fully compliant.

Another area that might also have attention is smtp extensions. But as we are implementing this library in our software now, we will only use smtp for development purposes. In production we have our own transport via rabbitmq, for business reasons you are likely to be most aware of!

Cheers,
Frederik

You can of course also have the MIME be created by your MTA/MailerQ. You can simply feed it with JSON objects holding all the properties: from, to, subject, text-version, html, attachments, et cetera. The MTA then converts that JSON into a MIME string and delivers it. That will save you a lot of time, code and complexity.

But I can understand that it is also simply fun to write a good mail library. It's a hell of a job, but it will bring you a lot of knowledge about how email works. Good luck! 😃

@EmielBruijntjes Yes, we can do that. But you need to do it yourself anyway, when doing non-mailerq deliveries, e.g. when testing.

I don't know about RFC 2822.

But for email validation : swiftmailer seems using https://github.com/egulias/EmailValidator , which is actually a port of https://github.com/dominicsayers/isemail . oh and yes https://github.com/auraphp/Aura.Filter also does have the same.

Good idea @harikt . I will have to do a little research to see what the best approach would be here.

sstok commented

https://github.com/egulias/EmailValidator (as harikt suggested) is also used by Swiftmailer and the Symfony Validator component (when strict email validation is enabled).

k00ni commented

What is the status here?

No progress. Feel free to suggest something through a PR.