Non-ascii email addresses and SMTP
Is there a way this letter will ever function? łōręmıpśum@łōręmıpśum.com
This isn't exactly a frivolous pursuit. We have polish users who have non-ascii input emails in our application.
The gmail validator invalidates it, but it might be such a rare case that they are not allowed to do so. The Punycode for "łōręmıpśum.com" is "xn--rmpum-j0a3o6e4dtg.com" and info@xn--rmpum-j0a3o6e4dtg.com
seems to work fine. However, the user part is giving me a headache.
I assumed that I could utf8 + percent encode it the same way as in the url (which ends up being "% C5% 82% C5% 8Dr% C4% 99m% C4% B1p% C5% 9Bum"), but The SMTP servers return my mail with an error:
The mail system
<%C5%82%C5%8Dr%C4%99m%C4%B1p%C5%9Bum@xn--rmpum-j0a3o6e4dtg.com>: host
eforward3.registrar-servers.com[38.101.213.199] said: 554 5.7.1
<%C5%82%C5%8Dr%C4%99m%C4%B1p%C5%9Bum@xn--rmpum-j0a3o6e4dtg.com>: Relay
access denied (in reply to RCPT TO command)
Final-Recipient: rfc822; %C5%82%C5%8Dr%C4%99m%C4%B1p%C5%9Bum@xn--rmpum-j0a3o6e4dtg.com
Original-Recipient: rfc822;%C5%82%C5%8Dr%C4%99m%C4%B1p%C5%9Bum@xn--rmpum-j0a3o6e4dtg.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; eforward3.registrar-servers.com
Diagnostic-Code: smtp; 554 5.7.1
<%C5%82%C5%8Dr%C4%99m%C4%B1p%C5%9Bum@xn--rmpum-j0a3o6e4dtg.com>: Relay
access denied
It looks like the letter goes through the local SMTP server, but is not deleted at the remote end. It is possible that the namecheap mail server is configured in ASCII oriented form.
My main question: I've already proven to myself that the server side of a letter can be Polish, but can the user side? If not, why not? It seems to me that the above email, while incredibly ugly, is just ASCII and shouldn't be handled specifically by postal systems that don't support unicode.
source to share
Unicode is a complete red herring; it has nothing to do with strange characters or encodings and anything to do with %
.
"Relay access denied" is the Postfix error message generated when you ask it to forward mail to another server. ("Open relays" were, and probably still are, a major source of spam problems in much the same way that open proxies make it difficult for an attacker to ban.)
So why does Postfix think you are asking it to relay this mail? Let's check the docs :
2.3.3.1. Open relay protection
Do not transfer mail from remote hosts to remote addresses! (If the sender is not authenticated).
This may seem obvious to most of us, but it seems to be often overlooked. In addition, not everyone may have a complete understanding of the various Internet standards related to email addresses and delivery paths (see "Percentage Domain Hacks", "bang (!) Paths", etc.).
Hold on, what? I don't think I have a complete understanding of all of these last two things.
A googling explains :
Years later, during the creation of CSNET, a different kind of relay notation was developed. The first instance of CSNET installed computers at RAND and the University of Delaware to provide email connectivity for non-ARPANET sites. To indicate the required relaying, a percentage hack notation was created so that the email address could be specified in the following form:
mary% compsci @Udel
The email address above indicates that user "mary" has an account on "compsci" and can be accessed through a relay site at the University of Delaware. The% sign was chosen because it was not used by any of the other popular e-mail systems and because it was visually similar to the "C / O" notation used to mean "care" for mail sent by mail. Even though the percentage hack involved multi-level relaying, its actual use was limited to one relay - one% and one.
The same page also explains the hacking use !
.
I don't think any of these behaviors are specified (hence "hack" ...); both %
and !
should be just symbols in the local part. But Postfix supports both of these hacks by default, so they are de facto reserved.
As for Unicode: Percentage encoding is only a URI and there is no reason to expect it to work anywhere in an email address.
RFC6531 extends SMTP to "international" characters. This is about as clear as any other email related RFC, but it looks like you can use UTF-8 on the local side and either the receiving server will figure it out via the SMTPUTF8 extension, or ... it won't. (Presumably, anyone with a local Unicode part is already using a mail server that understands Unicode.)
source to share