Hi,
I've tried a few times to write something.
I fail at writing anything involving alternate addresses. My problem is
that I think that if someone wants to use EAI and is required to supply an
ASCII alternative, then there's a decent chance that they'll forward the
ASCII alternative to their EAI address.
Which implies that if you can't send email to an EAI address, want to
communicate with the registrant and do it by sending mail to an ASCII
forwarding address, communication will break down as soon as the registrant
replies. That's feeble compatibility. A compatiblity feature should provide
more than that, or else it should IMO be dumped.
I see four options, and three of them are poor.
1. "EAI users MUST supply an ASCII address and MUST prefer ASCII when
replying to mail" — unrealistic.
2. "Anyone who wants to send mail to a registrant MUST be able to receive a
reply from an EAI address" — well, if they can receive, why not send?
3. "Anyone who sends mail to an ASCII alternate MUST be aware that a reply
may not be possible through no fault of the registrant" — what sort of
communication does that enable?
4. "Anyone who wants to send email to a registrant MUST be able to send
mail to EAI addresses"
The last is IMO the only workable option. EAI not that hard. All the top
MTAs support that in their latest version. Postfix and Exim, Halon and
Momentum, O365 and Gmail.
So that's what I suggest.
After what's currently section 3 ("Email address specification") I suggest
the following new paragraphs:
- snip -
Note that when an EAI contact address is used, some MTAs may not be able to
send mail to it, or receive responses from it.
This is similar to the existing situation with IPv6 and spam filters. An
MTA that has only IPv4 addresses cannot send mail to a contact address
served by IPv6-only MXes, or receive a reply from that contact address.
Some spam filters are said to reject as much as 99.9% of incoming mail,
which implies that an sender has far from a hundred-per cent chance of
being able to reach the contact, perhaps particularly if that sender is
unknown to the contact address' spam filter.
While this specification does not require anything, anyone who wishes to
communicate with a contact by email are required by circumstances to have
both IPv4 and IPv6 connectivity, pay attention to deliverabiliy issues, and
support SMTPUTF8 for both inbound and outbound mail.
- snip -
There is a risk that database layers might inadvertently change the address
and make it undeliverable. That shouldn't happen, but RFC 8264 hadn't been
published yet when e.g. the Oracle RDBMS was written, so I can see why one
might worry about that.
Therefore, I suggest the following new wording for the transform commands,
perhaps at the start of section 6.2:
- snip -
There is some concern that arbitrary user-supplied UTF-8 strings might not
be preserved in the registry's database. Therefore, when the the server
stores an EAI address as part of processing a mutating command such as
<create>, it MUST read the address from the database (in the same way as
when processing <info>), compare the address read with that supplied in the
command using byte-by-byte comparison, and return an error if there was any
discrepancy.
A future revision of this specification is expected to relax this
requirement.
- snip -
Which error should it return? I'm not sure and I don't care.
Arnt
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
