Add support for RFC6530, using it only when required.

[arnt]

This adds the ability to send email to addresses like grå@grå.org, but preserves phpmailer's old behaviour for all addresses that worked before (such as info@grå.org).

There's one new validator, which is like the W3c validator, but extended to cover EAI. It's sort of based on Firefox' extension of the same validator.

[Synchro]

Thanks for this – SMTPUTF8 support is something that's been wanted for a while, but I've been avoiding as I have not wanted to deal with the support issues it will inevitably cause when connecting to servers that don't support it, and also because I've wanted to avoid a half-hearted solution that only supports UTF-8 in addresses, not in all headers (which is what Symfony Mailer does).

However, I'm willing to persevere with your approach, especially since you wrote tests too :)

[Synchro]

Coincidentally, I wrote the pattern in the HTML5 spec!

[arnt]

Oh, did you? In that case I wouldn't mind having a chat about how it might be updated to cover EAI, if you have a spare half hour sometime. That github issue isn't going anywhere.

[Synchro]

One key problem that has stopped me pursuing SMTPUTF8 support in PHPMailer is that you can't tell ahead of time if the server supports it, so while you might provide UTF8 addresses that are valid during message construction, if the server doesn't support it it's not going to work. RFC6531 says the downgrade method is up to the MSA (i.e. PHPMailer), but how it should be handled is not defined, and it's not a simple problem to solve. Unfortunately the only reliable approach is to avoid using it altogether, which is where I've been sitting!

[arnt]

That part of 6531 is IMO not quite as well written as it could be.

When you walk through the various cases, the only one where a downgrade is both possible and better than an available alternative is MSA-time downgrade of the sender address. That's not a terribly relevant case for phpmailer (like for for mikel-mail, smtplib, javamail, or Sendgrid, Mailchimp, etc).

IMO, the kind of software that typically calls phpmailer is best served by using noreply@asciidomain as sender address and trusting the caller to supply the actually desired recipient address. Some phpmailer users might be seen as MSAs that could respond to errors by picking a different sender address, but that decision is IMO solidly outside phpmailer's scope.

Perhaps I should comment about how others do it... Ruby, Python and Java all have libraries that raise exceptions when something doesn't work. If the server refuses to play because we don't have the right password, they throw an exception. If the server won't relay because of a misconfiguration, another exception. The javamail/net-smtp/smtplib user is expected to catch the exceptions. I grepped around github to see what callers responded to those exceptions and didn't find any that distinguished between missing SMTPUTF8 and other exceptions.

So if it's bulk mail being generated from a database query, missing SMTPUTF8 will just add the relevant address to the list of undeliverable addresses. If it's a contact form, missing SMTPUTF8 will show up as the same error as if the server rejects the message (e.g., Postfix can reject unknown domains at injection time).

[Synchro]

I mentioned this earlier. You can check if the mail server supports an extension by looking in the SMTP::$server_caps array after EHLO has happened, like this:

array_key_exists('SMTPUTF8', $this->server_caps)

[arnt]

The check is easy, the next line is the question. I considered throwing an exception, but decided against it for the moment.

• I didn't want to have SMTPUTF8 behave differently from XVERP in that function
• Changing XVERP would change existing functionality (that noone should depend on, but...)
• Callers can disable exceptions anyway

I could of course call setError(), like how sendCommand() would do when the MAIL FROM fails. Shall I?

[arnt]

Hi,

I force-pushed with most things fixed. Remaining issues:

1. The code doesn't check whether SMTPUTF8 is supported before using it, to be similar to XVERT and because it doesn't make a difference (it only saves one roundtrip before throwing an exception).
2. There's no attempt at downgrading. There can't very well be, phpmailer isn't given enough information by its caller.

I could change both of these at once… I could add a callback with which phpmailer would ask its caller to downgrade. The default value would be a function that returns <> if it's the sender and throws an exception if it's a recipient address. Of course I'd add unit tests to make sure ascii@idn works. Does that sound good do you? Do you think you might merge that?

[arnt]

The more I think about it, the better I like that approach.

[PrOgramm3r1]

Unsubscribe

…

On Wed, Jan 17, 2024 at 15:55 Arnt Gulbrandsen ***@***.***> wrote: The more I think about it, the better I like that approach. — Reply to this email directly, view it on GitHub <#3000 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AU5TPSYWR5JMNJIFIM4XRSDYO7Q5XAVCNFSM6AAAAABBLHWEP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVHE3TMNZVGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>