Non-ascii characters in email addresses

Hi there,

I have just noticed in our JobDeliveryStatus logs that since july this year we have had 192 email non-deliveries with a DeliveryDetailType.State.Code 5 (Cancelled) and gammaCode 5130 (Invalid Internet email address). On investigation, these jobs have all been sent to addresses containing non-ascii characters such as æ, ø, å, ö.

I'm sure we must have attempted to send to similar addresses in the past, but we did not receive this gammaCode. Has there been a new rule implemented at EasyLink?

More importantly, are these addresses actually invalid? Will all addresses containing these characters always be blocked, and should we therefore capture them on our end first? I don't want to do that unless I am completely sure that they will be cancelled by EasyLink, and what the rules are.

Thanks,

Nick

Find more posts tagged with

Comments

skamens

We have not changed our address validation rules in many years. I would have expected you to receive these statuses any time such a character was included.

We do reject actual email addresses containing non-ascii characters. We allow these characters in the comment or name portion of the entry, just not the address itself.

If you can provide some examples we can confirm, but it's probably save for you to capture them on your end first.

nickspoon

OK, thanks for that.

Could you please give me a definitive list of characters that are allowed, so I can update our regex? Is it just [a-zA-Z0-9_-] ? That is:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_-

In fact, if you use a regex, could you share it so I know I'm using the exact same regex you are?

Thanks, Nick

skamens

We do not use a regular expression, unfortunately.

Your list above is pretty close. A couple of things that should be added:

'.' (dot)
'@' (at sign) - pretty important for an email address!
' (single-quote) - this is actually a supported character in an email address, and we have seen it used at times. A real pain when you're trying to parse for it!

nickspoon

OK, yeah the dots and @s are pretty crucial. So my character list is:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_-'

and can be used like this:

chars@chars.chars or chars@chars.chars.chars or chars@chars.chars.chars.chars

Does that look pretty accurate?

nickspoon

Ah, there can of course also be extra dots in the first section, before the '@'.

skamens

Yes, that looks pretty accurate.

We will look for at least one dot in the domain portion, but we don't have any limit on how many.

So it would be something like:

chars[.chars*]@chars.chars[.chars*]

(in crude regexp format)

nickspoon

Perfect, thanks for that.

One last thing - what about the characters '_' (underscore) and '+' (plus). Are they allowed?

(I know I've already included _ above, I'm just looking at our existing regex, where I can see we do allow + but don't allow _)

skamens

Underscores are definitely supported. I can't say that I see too may plus signs in email addresses, but we do support them.