Pretty light on details. By "prefix", do they mean the local part of email address? Like the "someuser" in "someuser@example.com" ?
If so, it's not that unusual that it wouldn't be supported. The local-part used to be constrained to ascii only. RFC6530 (SMTPUTF8) added UTF-8 support, but it's optional. Google only started supporting it in 2014, for example: https://googleblog.blogspot.com/2014/08/a-first-step-toward-... Microsoft has support in some places, but not others, etc.
> How can you run mail campaigns without access to these users? Ridiculous.
These users? You couldn't even email them from Outlook until just last year, 2016! How many users in the world would have accepted having an email account that no one using Exchange servers could handle? That cuts you (the user) off from hundreds of millions of people on corporate networks.
It's not just Exchange. RFC6530 support is pretty spotty.
Fastmail, which is pretty popular here, only allows a-z0-9_ in usernames. I don't see a "250 SMTPUTF8" reply when I connect to their server and EHLO. So, it's likely they don't support it either.
So apparently if you host your own domain with them they do?
However, they don't appear to support it for username@fastmail.com. Either for sign up, or for live delivery. http://imgur.com/a/Otf4f (see both images)
Try sending to 안녕@mydomain from a gmail account...it looks like they may not be supporting SMTPUTF8 correctly. Which could result in sending-to-yourself working, but not from an outside source.
I suppose... until you apply for a job and can't receive a favorable response because they're one of the many Fortune 5000 companies that use Exchange/Outlook somewhere in their infrastructure.
I had to reread some bits to figure out that they are talking about email addresses which MailChimp fails on if they contain non-ASCII UTF-8 characters in the user part of the address, not the actual email message.
For some reason this person calls an email address an email.
That blog post makes no sense until you substitute email for email address — non-ASCII UTF-8 characters in the body of an email is no problem provided the right encoding is used.
Perhaps other readers will find that useful to figure out the intended message.
Language nitpick: that should be the other way around, for meaning roughly instead of in this expression. I guess this might be going the way of comprised of and the like (once considered a clear error, but now so widespread that it's considered pedantic to reject it).
You should be downvoted, you're right and the order they used is wrong and requires your brain to rearrange it. If op wanted to use that ordering they should have used "with" in place of "for".
A year or two ago Cory Doctorow asked MailChimp how to get a list of all the mail lists an address is on and they wouldn't help him with that. MailChimp claims to be against spamming, but if that were true, I think they would give users a management screen.
Frankly, I agree with Mailchimp. Giving access to that information raises privacy issues (someone could potentially see that I'm subscribed to an embarrassing newsletter our at least use that information in phishing or advertising). Additionally it's a product that doesn't provide much benefit to Mailchimp and their paying customers
I suspect they meant that you'd use a check to make sure that you are in receipt of email to the address you want to check; similar to reset your password email, click the link in the email to prove it's your own email address.
Assuming a database or table per list owner, that's X separate queries where X is the total number of MailChimp customers. Don't see how that would be quick or easy. MailChimp says they have over a million customers.
"Note
Although MailChimp can process UTF-8 characters in most parts of our application, we cannot process UTF-8 characters in your subscribers' email address prefixes. We do accept Internationalized Domain Name (IDN) servers, so it’s alright to have UTF-8 characters in the domain name.
For example, we’ll block direcciónelectrónica@domain.com because the international characters are in the prefix, but we'll allow an address like test@ñoñó1234.com, where the characters are in the domain."
A bigger issue for me is that our ERP doesn't use UTF-8 for emails. I don't recall ever being told that this was a problem for our user base. We have a large number of contacts in Europe who forego their accents for the ascii equivalent
If so, it's not that unusual that it wouldn't be supported. The local-part used to be constrained to ascii only. RFC6530 (SMTPUTF8) added UTF-8 support, but it's optional. Google only started supporting it in 2014, for example: https://googleblog.blogspot.com/2014/08/a-first-step-toward-... Microsoft has support in some places, but not others, etc.