Support International characters!

[Luis_Paez3]

Why can't marketo support emailing email addresses with non-latin characters like this one?

schüchtern@somesortofnonexistentwebsite.de

Everyone should be using UTF-8, as it's a common, global data standard. From what we're seeing it looks like various major Internet Service Providers (and Email Providers) are allowing for the creation of emails just like the one above (and supporting many UTF-8 based characters). But in our marketo instance they're automatically marked as "Email Invalid". BUT THEY ARE MAILABLE IF I USE ANOTHER SERVICE

It's pretty simple, if you want more background, take a read of:

https://en.wikipedia.org/wiki/Extended_SMTP

which technically seems to indicate that RFC-6531 would support "Allow UTF-8 encoding in mailbox names and header fields" and isn't this now a published SMTP standard?

[SanfordWhiteman]

There's a lot more about Marketo's Unicode character support that is lacking or buggy. I have a humongous blog post about it in Draft.

Still, people who have SMTPUTF8 addresses aren't full citizens of the global web and need to understand that. It's not just Marketo as all transit servers need to be upgraded. IPv6 all over again.

[Colin_Mann]

100% agree - it should be simple for both uploading and APIs not-to-mention that it's also respectful, especially in countries like Germany where getting someone's name wrong is very poor.

[Casey_Grimes]

I would make the argument that if you have folks using UTF-8 in their domains (not the local inbox!) that you could just use a punycode conversion for now. If someone has UTF-8 in their local inbox, you could attempt a punycode conversion, but there's no guarantee that the mail server understands that.

Ideally, Marketo would do that conversion on the backend with no intervention from the user but I'm guessing it's still enough of an edge case to not make it worth it.

[SanfordWhiteman]

Yep, that's what FBUtil.string.punycode.toASCII is for in FlowBoost (I just had to say it ).

We've been seeing a huge influx of data w/UTF8 domains (Cyrillic in particular) and it's not exactly surprising that a spreadsheet cell would leave the data alone (as it should).

If someone has UTF-8 in their local inbox, you could attempt a punycode conversion,

Punycode is never legit on the left-hand-side of addresses.  It's only for domains, no mailserver should even try to understand it on the mailbox side or that mailserver is broken.

[Casey_Grimes]

Oh, to be clear, mail servers that go through punycode and sort into mailboxes/interpret local-part accordingly are definitely non-standard deployments (mostly Dovecot curiosities) and I wouldn't bank on it; perhaps I should have used stronger language than "no guarantee". I'm just noting there are a handful out there that have been modified. If anything, you're better off using the preferred anglicisation (i.e., schuechtern@somesortofnonexistentwebsite.de) and assuming there's an alias.

All that said, SMTPUTF8 addresses are a bit like using the address "this is v@lid!"@example.com. Yes, that is valid per protocol. No, you're probably not going to get much email to it with today's setups. Caveat emptor.

[SanfordWhiteman]

s "this is v@lid!"@example.com. Yes, that is valid per protocol. No, you're probably not going to get much email to it with today's setups. Caveat emptor.

Well, a standards-compliant mailserver must process that fine. The older the server software, the more likely it supports it, not less. I guarantee you're going to get loads more deliverability to a quoted address than an SMTPUTF8 address, if you send from a supporting client.

As far as broken email validation code on the client side, unfortunately you're more likely to sneak SMTPUTF8 through a validator, while quoted addresses (and, while we're grazing the topic, Punycode domains) will be erroneously caught by lots of supposedly "strict" validators out there. Uberflip just enraged me w/this the other day.

So it's a question of how you get the address on the wire. Once you get that quoted address on the wire its deliverability is gonna be much higher than SMTPUTF8.