Postfix has not changed, and won’t be changed, according to Wietse. The reasons for Postfix not allowing @ in usernames are valid, so it’ll never be recommended. It’s just an unfortunate fact of life that it seems common to use usernames of this format, and that Sendmail allows them–though I noted last time I looked at the cPanel docs that it isn’t the default, even there, and Plesk also offers several username delimiter types…so there’s nowhere that it is necessary to use this format of username.
Our solution to the problem is a kludge, but it is one that seems to work fine (and it actually avoids the problems that led to Wietse removing @ username support from Postfix). Issue 356 is, I believe, fixed in the current Usermin, but I might be wrong. I’m pretty sure there was a second bug filed for the same issue, and this particular one just didn’t get closed. I’ll have to look into it to be sure.
The solution we use is to create and manage two usernames for every user. One for Postfix that uses a sane format (no @), and another for Usermin, Dovecot POP3/IMAP, and optionally SSH access, which has the @. Actually either name will work for the other services, but only the non-@ name will work for Postfix mail delivery (and this comes from the virtual maps file, so no one ever sees it except Postfix and our tools that have to manage it). I believe even SMTP auth for outgoing Postfix service will work with the @ username (but I don’t remember if I’ve personally confirmed that). Oh, yeah, other webmail products will also generally work with the @ usernames.
There is now quite a bit of code in Virtualmin, Webmin, and Usermin to keep up with all of this stuff…but it seems to be working well now. Probably.
In short, it’s never going to be recommended because it’s just plain wrong. But, we’re not above doing wrong to make our customers happy.
So, if you go that route and run into problems, we will try to fix them. So far, we’ve never found any problems are insurmountable and hopefully we won’t find any that are. So, if it’ll increase customer confusion to change, then don’t change. But if you’re starting with all new user accounts, it’s better not to.