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
<exim-users@???> 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
<exim-users@???> 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
