Would bounces still work fine if your SMTP server supports SMTPUTF8 but the target server does not ?

Yes, you get a 5xx error when the supporting SMTP client sends to the unsupporting SMTP server.

The Symfony code is written to minimize the chance of running into this at all, though. If you send to e.g. info@grå.org, Symfony will be able to send that even to an unsupporting client. That's why the code tests for non-ASCII in the localpart (not the entire address). This is the same approach as e.g. Exchange.

I should elaborate. The 5xx error means that the server that generates the DNS is one that supports SMTPUTF8. It will generate a bounce that does not require SMTPUTF8 in order to be delivered, and which contains UTF8 in the body text.

It works quite well.

The Sender will become the recipient of the bounce. That's why I'm wondering how this would behave.

If the sender uses an ASCII address (highly advisable at this time), then the bounce does not require SMTPUTF8. Delivering the DSN is simple.

If the sender uses a non-ASCII address, then Symfony's upstream MTA will generate a DSN that uses SMTPUTF8, but in this case we know that the sender has support for that.

Bounces work reliably. My job (at ICANN) is one where I get to hear about this kind of problem ;)

If the recipient's server receives the message at all, then it supports SMTPUTF8. An extended server never forwards an SMTPUTF8 message to an unextended server. (This is a nontrivial design decision, and was made only after a large testbed experiment.)

This means that if any server along the path needs (or chooses) to bounce the message, then it has SMTPUTF8 support.

I wonder whether it makes sense to enforce ASCII in the sender's localpart… let me sleep on that, please. AIUI Symfony is used mostly to send mail from servers to users? Like a web server's noreply@example.com? Is Symfony also used by scripts that people like us run on the command line or from cron? There's a five-digit number of domains that actively use unicode email addresses, maybe even six-digit.

I have no idea what people build using symfony/mailer (nothing forbids you to write a PHP script meant to be run on the command line, and Symfony does not call home to report us that you did write such a script). However, my intuition is that at least 99% of usages (and probably much more than that) is about sending from a server

If the recipient's server receives the message at all, then it supports SMTPUTF8. An extended server never forwards an SMTPUTF8 message to an unextended server. (This is a nontrivial design decision, and was made only after a large testbed experiment.)

that's actually a good context to have to understand how this works.

I thought about forbidding UTF8 sender addresses, and…

I think the key here is that when people make the mistake of sending "here's the link to change password" or "your order has shipped" from a unicode address, they understand it really quickly. When you do that, maybe 20% of your outgoing mail bounces, and you change your configuration later on the same day.

It's not the kind of mistake that causes slow trouble over a long time, it's the kind of mistake that causes a lot of trouble immediately.

If, on the other hand, you write a script to process, sort and forward inbound mail, then you may not receive any from a unicode address very soon, and a limitaiton on sender address is one that shows up slowly, after a while, and seldom.

For this reason, I think the argument to forbid UTF8 sender addresses is fairly weak. But you can judge it better than I — my expertise is in unicode email and domain names, you know Symfony users and traditions.

If, on the other hand, you write a script to process, sort and forward inbound mail, then you may not receive any from a unicode address very soon, and a limitaiton on sender address is one that shows up slowly, after a while, and seldom.

wouldn't those fail DMARC checks if you forward them using the original sender ?

I would vote for keeping the restriction on UTF8 sender, which will give immediate feedback to devs instead of waiting for them to get trouble with their delivery once reaching production (if they attempt to use an Unicode sender, it is likely that their own email servers will support them and so they won't get delivery issues in dev/staging)

I've never seen any of those scripts do external forwarding, which would subject the message to DMARC tests. People write code to sort mail to info@… into different classes, route some to autoresponders and some to various local addresses. If the body text mentions product x, the message is forwarded to address y, etc. Some companies make sure a Key Account Representative get a copy of mail to/from key customers.

Some mail servers can do that with rules, but if a company employs developers, it's often done in the language those developers use.

I'll add another commit that reinstates the restriction on the localpart, with a unit test or two that make sure of compatibility with all receivers. You can include or exclude that commit when you merge the PR (I do hope you'll merge). IMO both approaches are good, the choice of best is a matter of Symfony's philosophy.