Subject: [EAI] 6531, rcpt to:.... orcpt=...

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 9 May 2014 21:18:54 +0200

Hi,

I don't see any mention of orcpt in 6531. The general idea is that the smtp 
client uses u-labels encoded with the usual xtext blah and the server 
treats it as an opaque string, is that right?

Arnt

---

From: [email-masked]
Date: Sun, 11 May 2014 10:01:48 -0700 (PDT)

> treats it as an opaque string, is that right?

This is discussed in section 3 of RFC 6533. And it isn't that simple: The
definition of the new utf-8 address complicates things considerably.

This is one of the most tedious parts of EAI for me to implement. FWIW.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 12 May 2014 15:57:26 +0200

> definition of the new utf-8 address complicates things considerably.

Yes, so I see.

The second paragraph of section 3 is the one I was surprised not to see in 
6531.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 12 May 2014 16:15:03 +0200

6533 doesn't quite have the air of elegant simplicity that gilds 6531 and 
6854.

   When sending data to a SMTPUTF8-capable server, native UTF-8
   characters SHOULD be used instead of the EmbeddedUnicodeChar syntax
   described below.  When sending data to an SMTP server that does not
   advertise SMTPUTF8, then the EmbeddedUnicodeChar syntax MUST be used
   instead of UTF-8.

And what about DSN generators that have no idea about any of that? Such as 
ones that are only permitted to write to a spool, not to open SMTP 
connections anywhere? Suggestions, anyone?

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 12 May 2014 16:23:38 +0200

I'm confused. Forget that. Sorry.

Arnt