Trying to tie up loose ends that may be left over from my prior response...
--On Monday, April 27, 2015 15:10 +0000 Viktor Dukhovni <[email protected]> wrote: > Neither MTAs nor MSAs should attempt to apply Punycode > encoding to UTF-8 EAI email address localparts. The only > acceptable alternative representation that comes to mind is a > table of ascii-only addresses explicitly configured for > senders in the MSA's local domains, that are accepted on the > reverse path as valid addresses for these same senders. With > that, you could encode sender addresses when forwarding > ascii-only recipients to non-EAI systems (or sending email to > recipients in the same domains for which ascii-only forms > exist). > > In other words any such encoding is a local matter, and can be > applied only at the system responsible for the domain. Yes. There is a second alternative with much the same effect, which is for receiving systems to broadcast acceptable aliases and associated relationships. During the development of the Experimental version of the EAI specs, the WG spent time considering, e.g., LDAP databases that could do just that, possibly associated with DNS SRV records for locating the associated databases for a given email domain. They/we finally gave up -- just too complicated to accept general adoption and even more complicated if one wanted to worry about attacks. Victor's "strictly local" idea would work, but is essentially a way for a sending system to pretend to its users that it is supporting non-ASCII addresses without doing so ... and doing absolutely nothing for forward-pointing non-ASCII addresses. That would be justified if an MSA, as a matter of policy, viewed an MUA's attempt to use a backward-pointing non-ASCII address as "unfortunate behavior" and was prepared to reject messages containing forward-pointing non-ASCII addresses. Even then, I'd hope the behavior would be controlled by configuration options that would default to "don't do that". --On Monday, April 27, 2015 16:01 +0000 Viktor Dukhovni <[email protected]> wrote: >... > On what basis is encoding localparts in remote domains a > reasonable transformation that an MTA or MSA might apply? > When might Exim apply it? An in-transit MTA, never. The language of 5321 about tempering with local-parts clearly applies. For an MSA, MSAs are allowed to use just about any external knowledge they can get their hands on to make things work better. So, if I, as a user or administrator of an MSA, supplied a table of remote addresses and said "if you see this address, substitute that or apply this procedure", RFC 6409 certainly allows that and allows a conforming MSA to have provisions to do that. I imagine I could figure out ways to make Exim do that now (and that others who are more expert could do so more easily), but the situation would, IMO, be fairly rare unless almost all of one's correspondents were associated with a very small number of recipient systems. On the receiving side, I'd be very upset if Exim tried to apply a decoding except by means of a mechanism that could be applied on a per-receiving-address basis. Again, whether decoding would be desirable depends on the capabilities of the MUAs that are likely to be used. In most systems, that is a per-address (or per-user) determination. best, john -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
