Subject: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 5 Mar 2012 11:38:51 +0800

Dear all,

   This draft was triggered by  email software providers when we discussed the eai implementation with them.
   Any comments are welcome.

Jiankang Yao

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 05, 2012 10:57 AM
Subject: I-D Action: draft-yao-eai-dns-00.txt

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : SMTPUTF8 Capability Indicator
> Author(s)       : Jiankang Yao
>                          Shuo Shen
> Filename        : draft-yao-eai-dns-00.txt
> Pages           : 6
> Date            : 2012-03-04
> 
>   Key RFCs for internationalized email addresses specify the basic
>   protocols for using them.  The SMTP client can only know the SMTP
>   server's ability by EHLO command.  In order to help the
>   internationalized email address delivery, this document suggests to
>   add the new DNS RR type for internationalized email protocols.
>   Through this RR type, the SMTP client can know whether the
>   destination SMTP server can support the SMTPUTF8 ability before
>   sending the EHLO command to the server.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yao-eai-dns-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-yao-eai-dns-00.txt
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: [email-masked]
Date: Sun, 04 Mar 2012 20:20:44 -0800 (PST)

>    Any comments are welcome.

First, I have to say that given the present state of play of the DNS, I am
extremely skeptical that a new RRTYPE can actually deploy soon enough to be
useful. And that's assuming you are able to get it through the process quickly,
which is also unlikely.

Sadly, the DNS folks are in total denial as to the issues and AFAICT see no
value in working on mechanisms that would improve the situation. And even if
this were to change, you're at best talking about improving the situation for
RRTYPEs developed years from now.

Second, the text you have is very confusing; at one point you say the
record returns a list of domains, at another point you imply they are
actually host names. Wordsmithing definitely needed.

Third, if I understand the proposal (and I may not), I also have to say that
the semantics are more than a little ugly. You look up a domain and either get
back "all", which is fine, "no", also fine, or a list of EAI-suppporting hosts
- ick. You are then supposed to intersect that list with the list you get back
from from your MX query, correct? That's going to be a fair bit of work and I
suspect a lot of implementations won't bother.

It would be much better to use SRV for this, making it an alternative to MX for
the EAI case. And it avoids having to compute the intersection; you just
specify the EAI-capable hosts, done. The "all" and "no" case are served by not
having an entry; then you try the MX and either succeed or fail. And SRV has
the huge advantage of being deployed. 

And if you stick with the intersection approach, I don't think a list of domain
names packed into a single string is the way to do it. Multiple records
containing name fields fields are a better bet because they support
compression, and compression can make a big difference when there's lots of
repetition in the names, as seems likely. (I note in passing that you get this
for free with SRV.)

This is also one case where TXT records really do not make sense as an
alternative, again because of compression issues. If you're going to overload
something, overload SRV - it's actually designed to be overload in this way.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 6 Mar 2012 01:13:18 -0000

>   Any comments are welcome.

The normal way to find out who accepts EAI mail is to look up the MX
records and corresponding A and AAAA records, connect in the usual
way, and see whether the response to EHLO includes SMTPUTF8.  It would
be quite reasonable to keep a local cache that remembered for each A
and AAAA, whether the it does SMTPUTF8 or not.  That could help avoid
useless EAI connections to hosts that don't support it.

Can you explain why the software providers you talked to aren't
willing to do this?  As other people have noted, doing anything
else would be a major change to the way that mail works.

R's,
John

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 6 Mar 2012 11:25:33 +0800

Thanks a lot for  all comments from the wg members.
Here are some clarifications:

1) my intention is to help the deployment of eai protocols. 
2) In Feb. 2012, I talked with many email software and service providers in China.  some software providers in China have promised to implement and deploy rfc6531 and rfc6532.
3) the idea in the draft was discussed during Feb. 2012 when I takled with them. They thought that some mechanisms with an early indicator of whether the destination server support SMTPUTF8 would help the deployment of RFC6531 and RFC652 during the early deployment of EAI.
4) this draft is mainly for discussion about how we can help the deployment of EAI. If the WG thinks that it is not good idea, we can just discard it.
5) the scenario which the email software or service providers would like to address is that eai users send the eai message to many users including eai user and ascii user.

 For example, if an internationalized message is sent to 10 users one of which is an ASCII user, the MSA may have
   to say EHLO 10 times before deciding to reject the message.  This
   procedure of judging whether the SMTP server is SMTPUTF8-aware is
   time-consuming. 

[email-masked] sends the eai message to

1) [email-masked]
2) [email-masked]
3) [email-masked]
4) [email-masked]
5) [email-masked]
6) [email-masked]
7) [email-masked]
8) [email-masked]
9) [email-masked]
10) [email-masked]

if all ten users support smtputf8 and the MSA know it in advance, the message will be sent one by one from 1) to 10).

if user 10) [email-masked] does not support smtputf8, but other nine users support smtputf8, 
the MSA may say ehlo to  the destination server one by one from 1) to 10),   and finally decide to reject it.

of course, there are many solutions to this issue such as John levine's cached mechanism.

I just bring some deployment issues here.  If the wg think that it is not worth,  pls just discard it.

Jiankang Yao

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Mar 2012 22:29:56 -0500

Hi,

On Sun, Mar 04, 2012 at 08:20:44PM -0800, [email-masked] wrote:

> value in working on mechanisms that would improve the situation.

Just so that we're clear here: are you talking about the
much-complained-of problem that provisioning systems are brain-dead
with respect to unknown RRTYPEs (a complaint that I understand and
sympathise with), or some other problem?  For the DNS RRTYPE proposed
in the draft could have its typecode within a matter of weeks, even
though I happen to think that the proposal is a bad idea and would
waste a perfectly code typecode.  (Indeed, last year we allocated two
such typecodes.)

I find it a little hard to believe that an organization willing to go
to the effort of deploying a fairly significant extension to SMTP,
including all the surrounding infrastructure, is going to balk at
upgrades to their DNS provisioning tools.  Compared to, for instance,
the validation rules behind every single mail-address box on every web
form in the known universe, DNS provisioning tools at the site turning
on EAI have got to be low on the "hard to fix" list.

If the problem is that applications can't use unknown RRTYPEs, then I
beg to differ: we see them implemented all the time, particularly at
the level where systems that are communicating over SMTP are.

I don't think it helps anyone to make sweeping generalizations about
"DNS folks" and their collective state of mind.  I carry no water for
the draft in question -- I agree with the other concerns that have
been raised -- but I don't see how the supposed difficulty in coping
with the DNS has anything to do with the problems here.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: [email-masked]
Date: Mon, 05 Mar 2012 21:27:41 -0800 (PST)

> sympathise with), or some other problem?

I'm talking about the refusal to lift a finger to address the parts of the
problem we do have control over. (We can't solve the braindead provisioning
problem, but we can sure as hell make it a lot easier to write non-braindead
provisioning systems.) I'm talking about posting frank nonsense like the
assertion that adding an entry to a configuration file isn't materially
different from patching or upgrading a piece of critical infrastructure
software to a new version.

I could go on and list other examples, but since this is largely irrelevant in
this forum I think this suffices.

> For the DNS RRTYPE proposed

I agree that this draft is a bad idea for other reasons. Nevertheless, I stand
by my assertion that new RRTYPEs would be a problem if this draft were to go
forward in the present form.

> upgrades to their DNS provisioning tools.

I can assure you, based on 20+ years of experience dealing with exactly these
sorts of sites on pretty much a daily basis, that it is 100% true.

Part of the problem is that these are large organizations and different
services are provided by different parts of the organization. The folks who
control DNS provisioning and upgrades are not the same as the ones who operate
the email systems. In a lot of cases a request to upgrade critical
infrastructure to a new version that doesn't coincide with their own schedule
will be met with, "Stick it where the sun don't shine." Or worse.

Heck, only today we were having an internal argument about the feasibility of
using SRV records for some internal purposes - and they have been around for
many years. (In this case I was the one arguing that they are now feasible to
use due to various services like SIP and XMPP that depend on them having
deployed, others in our organization with significant technical competence
disagree and think we should avoid them. And it's possible I'm wrong and they
are right.)

> Compared to, for instance,
> form in the known universe,

Well, you're significantly overstating the difficulty of constructing
rules for what I'll call the useful subset of email addresses, but that's
not really relevant to the matter at hand.

> DNS provisioning tools at the site turning

I disagree, but even if you're right technical difficulty is not the only, nor
in many cases the most important, factor.

> "DNS folks" and their collective state of mind.

That's your opinion. I don't share it. I'm sick and tired of their crap, and in
this forum I'm not going to mince words about my opinion of it.

> I carry no water for the draft in question -- I agree with the other concerns
> that have been raised -- but I don't see how the supposed difficulty in coping

Spend a few years writing and supporting software for the folks running mail
systems at large ISPs, and I can assure you your position would change.

				Ned

---

From: [email-masked]
Date: Mon, 05 Mar 2012 23:18:56 -0800 (PST)

>    to say EHLO 10 times before deciding to reject the message.

Say what? I would expect in this case for the message to be delivered to the
first 9 recipients and for the 10th to generate a DSN. That's the only sensible
outcome, and moreover, the idea of having to get responses from multiple
systems before deciding whether or not to reject the message in toto is both an
implementation nightmare as well as operationally infeasible.

What if one of the systems you have never talked to before is down for a
prolonged period longer than the MSA or MTA's queue timeout? Do you seriously
think it's a good idea to have a message sit in the queue for a week and then
time out and bounce for all recipients because of that?

I also note that nothing in the EAI document set requires, or for that matter
even encourages, such behavior.

>    This

No, it really isn't. Modern MTAs at a minimum split such messages by
destination host and perform deliveries in parallel. (Note that this is the
minimum they do; there are many additional optimizations that can be performed,
with varying degrees of effectiveness.)

> will be sent one by one from 1) to 10).

Again, your understanding of how modern MTAs work is incorrect. It is very
likely, in fact nearly certain, that the message will go out with some degree
of parallelism. And the results of delivery to one recipient are not
coupled to the results of others.

I will also point out that as a practical matter, you cannot possibly guarantee
these sorts of results no matter what implementors do. What if one of the
systems says it supports EAI but then rejects the recipient during the SMTP
dialogue because that _recipient_ doesn't support it? Or what if the system
accepts the message but decides to reject it later because that recipient is
later determined to not support EAI? Either way you've lost your "all succeed
or all fail" capability. And having such behavior in some cases but not others
violates the least astonishment principle.

> if user 10) [email-masked] does not support smtputf8, but other nine users
> support smtputf8, the MSA may say ehlo to  the destination server one by one
> from 1) to 10),   and finally decide to reject it.

I doubt very much any MSA will implement that strategy, for reasons given
above. And it certainly isn't required that they do so.

> of course, there are many solutions to this issue such as John levine's

I'm afraid most of the problems you're attempting to address here are based
on a misunderstanding of how this is going to work.

As for caching EHLO repsonses, that actually makes me a little nervous. Caching
positive responses is fine but not particularly useful, caching negative  ones
OTOH for any length of time risks the the possibility that the system will be
upgraded and messages will get bounced for no good reason. 

				Ned

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 6 Mar 2012 16:40:34 +0800

----- Original Message ----- 
From: "Ned Freed" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 06, 2012 3:18 PM
Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt

> outcome 

there is a problem here.

When you send a message to 10 users, 9 users(A B C D E F G H I) recieve the message. 1 user (K) can not receive it.

question 1 ) what is your next step to deal with the user who can not receive it?

1) you use your ascii address to send the message privately to the user (K) who can not receive it

2)just ignore it and do nothing

question 2) how 9 users(A B C D E F G H I) reply the message received?

the problem is that user (K) is in the recipients list but never recieve the message unless the sender forwards or resends the message privately to user (K).

Jiankang Yao

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 6 Mar 2012 09:50:57 +0100

> When you send a message to 10 users, 9 users(A B C D E F G H I) recieve the message. 1 user (K) can not receive it.

We've had this problem for thirty years. It's not an EAI problem. EAI
just adds one more case in which it can happen.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Mar 2012 05:04:37 -0500

Andrew,

FWIW, my experience agrees with Ned's.  Even in a centralized
environment in which responsibility for applications services
(SMTP servers in this case) and responsibility for
infrastructure ones like DNS servers lies with the same group,
there are innumerable reasons why upgrade schedules for one
might be quite different from upgrade schedules for another or
why there might be much more reluctance to upgrade one than the
other.  For example, because an SMTP server affects only a
single application, changing it might require only signoff from
the SMTP subgroup or person but, because a DNS server affects
many applications, changes might require multiple signoffs.
Even if we were able to agree that many or most of those reasons
for differences were wrong-headed, that agreement would make
absolutely no difference in practice.

Along those same lines, the argument that "all one has to is to
change some tables and recompile" is likely to be treated as
utter nonsense by someone who can easily resist pressure to
upgrade things but who can get fired for creating instability
(whether the local capability for rebuilding and recompiling
actually exists in practice is also irrelevant in many cases).
I've worked in environments in which the commitment to absolute
stability of any application seen by the user is strong enough
that simple recompilation with unchanged source code is not
considered a safe transformation.  Unless the compilers are
provably bug-free (good luck with that!), that concern is real
unless one can guarantee that the recompilation uses the same
version of the compiler and all relevant supporting tools.  You
or others might believe that level of concern is excessive.  On
some days, I might agree.  But our beliefs are worth just about
nothing.

FWIW, if I were responsible for significant DNS server software
or designing new RRTYPEs, and were serious about making new
RRTYPEs easy to deploy, I'd skip fairy tales like "you can
easily recompile" in favor of thinking through the question of
what would constitute a minimal description language for RRTYPEs
that could be interpreted (if it needed to be more complex than
LR(0), I'd suggest we are in serious trouble) such that while
known (older) RRTYPEs could be optimized into code, new ones
could be tested and added with an absolutely minimal risk of bad
consequences to anything else by adding a new rule to an
interpreted table (or a new table to a set).  If the server code
then shipped with configuration options to either locate the
table(s) or disable lookup and interpretation for new RRTYPEs,
we'd be having a rather different discussion, IMO.    Such
interpretative rules are not rocket science and would overcome
most (although definitely not all) of the practical objections
to "just deploy a new RRTYPE" that Ned, myself, and others are
raising.

But while it seems obvious, no one seems to want to do that.
Possibly computing the amount of thrust needed to get a pig
airborne is more interesting :-(

    john

--On Monday, March 05, 2012 21:27 -0800 [email-masked]
wrote:

>> > First, I have to say that given the present state of play
>> > of the DNS, I am extremely skeptical that a new RRTYPE can
>> > actually deploy soon enough to be useful. And that's
>> > assuming you are able to get it through the process quickly,
>> > which is also unlikely.
>> > 
>> > Sadly, the DNS folks are in total denial as to the issues
>> > and AFAICT see no value in working on mechanisms that would
>> > improve the situation.
> 
>> much-complained-of problem that provisioning systems are
>> brain-dead with respect to unknown RRTYPEs (a complaint that
>> I understand and sympathise with), or some other problem?
> 
> I'm talking about the refusal to lift a finger to address the
> parts of the problem we do have control over. (We can't solve
> the braindead provisioning problem, but we can sure as hell
> make it a lot easier to write non-braindead provisioning
> systems.) I'm talking about posting frank nonsense like the
> assertion that adding an entry to a configuration file isn't
> materially different from patching or upgrading a piece of
> critical infrastructure software to a new version.
> 
> I could go on and list other examples, but since this is
> largely irrelevant in this forum I think this suffices.
> 
>> in the draft could have its typecode within a matter of
>> weeks, even though I happen to think that the proposal is a
>> bad idea and would waste a perfectly code typecode.  (Indeed,
>> last year we allocated two such typecodes.)
> 
> I agree that this draft is a bad idea for other reasons.
> Nevertheless, I stand by my assertion that new RRTYPEs would
> be a problem if this draft were to go forward in the present
> form.
> 
>> I find it a little hard to believe that an organization
>> willing to go to the effort of deploying a fairly significant
>> extension to SMTP, including all the surrounding
>> infrastructure, is going to balk at upgrades to their DNS
>> provisioning tools.
> 
> I can assure you, based on 20+ years of experience dealing
> with exactly these sorts of sites on pretty much a daily
> basis, that it is 100% true.
> 
> Part of the problem is that these are large organizations and
> different services are provided by different parts of the
> organization. The folks who control DNS provisioning and
> upgrades are not the same as the ones who operate the email
> systems. In a lot of cases a request to upgrade critical
> infrastructure to a new version that doesn't coincide with
> their own schedule will be met with, "Stick it where the sun
> don't shine." Or worse.
> 
> Heck, only today we were having an internal argument about the
> feasibility of using SRV records for some internal purposes -
> and they have been around for many years. (In this case I was
> the one arguing that they are now feasible to use due to
> various services like SIP and XMPP that depend on them having
> deployed, others in our organization with significant
> technical competence disagree and think we should avoid them.
> And it's possible I'm wrong and they are right.)
> 
>> the validation rules behind every single mail-address box on
>> every web form in the known universe,
> 
> Well, you're significantly overstating the difficulty of
> constructing rules for what I'll call the useful subset of
> email addresses, but that's not really relevant to the matter
> at hand.
> 
> I disagree, but even if you're right technical difficulty is
> not the only, nor in many cases the most important, factor.
> 
>> If the problem is that applications can't use unknown
>> RRTYPEs, then I beg to differ: we see them implemented all
>> the time, particularly at the level where systems that are
>> communicating over SMTP are.
> 
>> I don't think it helps anyone to make sweeping
>> generalizations about "DNS folks" and their collective state
>> of mind.
> 
> That's your opinion. I don't share it. I'm sick and tired of
> their crap, and in this forum I'm not going to mince words
> about my opinion of it.
> 
>> I carry no water for the draft in question -- I agree with
>> the other concerns that have been raised -- but I don't see
>> how the supposed difficulty in coping with the DNS has
>> anything to do with the problems here.
> 
> Spend a few years writing and supporting software for the
> folks running mail systems at large ISPs, and I can assure you
> your position would change.
> 
> 				Ned
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Mar 2012 05:18:31 -0500

--On Tuesday, March 06, 2012 09:50 +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

>> When you send a message to 10 users, 9 users(A B C D E F G H
>> I) recieve the message. 1 user (K) can not receive it.
> 
> We've had this problem for thirty years. It's not an EAI
> problem. EAI just adds one more case in which it can happen.

More as an aside than because it has direct relevance here, but
I remember conversations about this issue a very long time ago,
perhaps in the context of email systems that existed prior to,
or in parallel with, RFC821/822.  It is very attractive to try
to design a system so that, if A sees a message whose headers
show herself and B C D E F G H I K as recipients, she should be
able to know that all of them received and saw the message.  It
has been a long time but, if I recall, VRFY came into our world
partially because of a desire to be able to validate all ten
recipient mailboxes and then send the message to all of them
with some assurance of deliverability.

The difficulty is that, as soon as one considers recipients on
multiple target systems, it is basically impossible for the
reasons Arnt and Ned point out (and some others). Even in a
single target system that is that same one on which the sender's
mailbox and submission server are located, there is the
possibility of race conditions with "mailbox full" or even
"account deleted" after the VRFY process completes.  That
possibility would exist even if VRFY reported
presumably-temporary conditions like "mailbox full", which it
does not.

It is perhaps also worth noting that the guarantee of delivery
to everyone doesn't exist with postal mail either.   If I
address a postal letter to a recipient and indicate that I'm
copying several other, then put copies of the letter into
separate envelopes and mail/post them, there are no guarantees
that all of them will be delivered and failures can occur for a
rather large variety of reasons: the "cc" list is a statement of
intent, nothing more.

There _is_ a reason why some idea like establishing capabilities
in the DNS might be attractive if it would actually work and be
provisioned correctly in the vast majority of cases and that is
for the submission server (or even the originating MUA) to be
able to find out if the recipient can accept SMTPUTF8 messages
even if no direct connectivity exists.    That has nothing to do
with the multiple-recipient delivery situation but could be
useful in determining whether a message would need downgrading
or remapping in the submission server or earlier.  But getting
all of the submission bits correct would not be straightforward
and, if the advice we've given about capabilities in
MX-specified relay hosts is followed, the marginal value is
probably far outweighed by the need for sender code to deal with
a more complex environment and likelihood of misconfiguration.

So, Jiankang, I think your colleagues are thinking about the
problem incorrectly, or at least naively, and the reasons go far
beyond the particular properties of SMTP (much less
EAI)/SMTPUTF8).

best,
    john

---

From: [email-masked]
Date: Tue, 06 Mar 2012 07:08:18 -0800 (PST)

> there is a problem here.

I'm sorry, but there really isn't - at least there's no new problem that users
don't already face all on a regular basis.

> question 1 ) what is your next step to deal with the user who can not receive

The same as whatever you do when one of the users you sent to can't receive
your mail now: Redo your message, so it's acceptable, call them on the phone,
IM them, ignore the problem, whatever. This happens *all* *the* *time*, and
when, say, your message is larger than the limit that site accepts, the
condition may be every bit as permanent as if you tried to send them an EAI
mail and they don't support that.

This is has always been how email has worked. Users have been coping with it
for decades. They don't seem to have a problem doing so.

> 2)just ignore it and do nothing

And there are plenty of other options, as shown above. One option that would be
really nice is if the user's client would correlate the failure with that
address and would warn the user the next time they try and send that person an
EAI message. This sort of correlation is entirely doable given the structured
response format defined in NOTARY, but to date I have yet to see a single
solitary client actually do this sort of thing.

> question 2) how 9 users(A B C D E F G H I) reply the message received?

They also get a DSN. and have to cope with it. I currently have this happen to
me about once a week when someone sends me a message with one or more invalid
recipient addresses in the header. No EAI is necessary for this to happen.
Sometimes I know what the correct address is, other times I do not. Sometimes I
cannot even figure out which of the addresses the message is being sent to is
failing, so I don't even know which address to remove when I reply the next
time. I have no choice but to live with the DSNs in that case.

> the problem is that user (K) is in the recipients list but never recieve the
> message unless the sender forwards or resends the message privately to user
> (K).

Yup. And that's how email works right now. EAI changes nothing except to add
another possible failure case.

The experimental documents already explored the option of trying to mandate
fallback addresses everywhere so that downgrading was possible in the transport
infrastructure, which is the only way you can possibly address this failure in
the EAI case. It failed. One of the unavoidable consequences of that failure 
is that EAI joins the long, long list of other sources of these issues. And
there isn't a single solitary thing you can do about it. Your proposed DNS
hackery cannot possibly address the issue, for the reasons I have already
outlined.

Again, some, but by no means all, of these issues can be mitigated to some
extent by using a smarter client. But I'm very skeptical that the folks
building clients will actually engage in any mitigation of these issues. They
have never done so in the past, despite our providing them with every tool they
need - NOTARY in particular - to make it possible.

If this is coming as a late surprise to you I'm sorry, but it's been implicit
in the approach we've taken from the get-go.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 6 Mar 2012 16:25:29 -0000

>upgraded and messages will get bounced for no good reason. 

I was assuming you'd cache them for the TTL of the MX or A that points to it, not
forever.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Mar 2012 17:39:39 +0000

> repetition in the names, as seems likely. (I note in passing that you get this

While I very much agree with this, compression is not the reason: only RR
types mentioned in RFC 1035 are subject to compression, and that doesn't
include SRV. See RFC 3597 "Handling of Unknown DNS Resource Record (RR)
Types".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: North 5 or 6. Moderate or rough. Fair. Moderate or good.

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Mar 2012 18:46:34 +0000

I think this might be a little bit useful when receiving messages. My
servers check the DNS for remote domains when receiving mail from them as
a basic sanity check. It might be helpful when receiving mail from an
EAI address to be able to perform a lightweight check that the domain's
server is in fact internationalized.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover, Wight, Portland: Variable, becoming southwest, 3 or 4,
increasing 6 to gale 8, perhaps severe gale 9 later in Dover and Thames, then
veering northwest 5 to 7 later. Slight, becoming moderate or rough. Rain and
drizzle for a time. Good, occasionally poor.

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 7 Mar 2012 12:00:23 +0800

----- Original Message ----- 
From: "Ned Freed" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: "Ned Freed" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 06, 2012 11:08 PM
Subject: Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt

> for decades. They don't seem to have a problem doing so.

I think that there has a little difference here.

In the pure ASCII email world, some users in the recipients list may lost the mail due to one or another reason. but after adjusting something,
they have a big chance to receive the message. So in the most cases, the message losing is temporary.

when EAI email word interacts with the ASCII email world, some users in the recipients list may never receive the mail sent to them.

I think that most users can bear the temporary failure of message delivery, but is unlikely to bear the permanent failure of message delivery.

Jiankang Yao

---

From: [email-masked]
Date: Tue, 06 Mar 2012 19:29:02 -0800 (PST)

(This is almost entirely off topic for EAI, but I think increased awareness of
the work I'm going to describe would be good, so I'm going to post this one
last reply to the EAI list.)

> that could be interpreted

This is exactly what John Levine is attempting to do in
draft-levine-dnsextlang-02.txt. He went through the entire list of previously
defined RRTYPEs to come up with a list of all the binary data formats and their
associated presentation format in standard zone files that are used in DNS
records. He ignored the ones that have complex interactions with the server
itself, e.g., the ones associated with DNSSEC.

It turns out the list is actually pretty short: integers (1, 2, or 4 bytes),
IPv4 and IPv6 addresses, domain names (compressed or uncompressed,  qualified
by whether or not the server should fetch associated A records), stirngs
(short, long, multiple), base64 (counted or uncounted), and hex. That's it. He
then devised a very simple language for describing this that can be used to
define new records. There's also a way to add new types, if that's ever
necessary.

This language could be used by servers to extend them to handle new record
types without the need for any upgrades. It can even be consumed by web
interfaces and used to build web forms automatically.

IMO this would address at least some of the issues involved in getting new
records deployed. There is often a HUGE difference in doing upgrades versus
adding an entry to a configuration file. Mind you, it's not going to address
the more draconian corporate policies, but at least it can help get us past the
"we're not upgrading on your schedule" thing.

In fact it was the huge collective yawn from I heard multiple DNSop folks this
proposal received that spurred me into my earlier rant. No, this doesn't solve
every problem. But it's a step in the right direction.

> (if it needed to be more complex than
> interpreted table (or a new table to a set).

Exactly the intent here. I suggested adding a type that would allow either an
IPv4 or an IPv6 address; John Levine pushed back on it, saying that no existing
type uses such a mechanism and he wants to limit this to tried and true data
and presentation formats, in part to be able to make a legitimate claim to
minimal risk.

> If the server code

*exactly*

> airborne is more interesting :-(

That's exactly the problem - we have yet to convince people of the value of
this sort of scheme. (I actually think the biggest problem with it is that we
didn't do it 15 years ago.)

Anyway, if people think this is a good idea, they need to speak up on the
main IETF list. And preferably review the draft and comment.

				Ned

---

From: [email-masked]
Date: Tue, 06 Mar 2012 21:45:46 -0800 (PST)

> I think that there has a little difference here.

There is, but it's the opposite of what you think.

> In the pure ASCII email world,

We left pure ASCII behind 20 years ago. Calling it that misstates
the situation substantially.

> some users in the recipients list may lost the
> mail due to one or another reason. but after adjusting something, they have
> a big chance to receive the message.

Depends on what the problem is. As a practical matter, these days the most
likely cause of mail rejection is incorrect labelling as spam, and a common
cause for that is improper blacklisting of the sender's mail server.

Such blacklisting is usually something the sender can do nothing about. And
there are plenty of other reasons, such as the recipient being over quota, that
the sender can do nothing about.

In fact these days I rarely get DSNs for conditions I have any option
of fixing.

> So in the most cases, the message losing is temporary.

Sorry, that's simply incorrect.

> when EAI email word interacts with the ASCII email world, some users in the
> recipients list may never receive the mail sent to them.

Actually, in this case the sender has the option of sending a non-EAI message
to that recipient. MIME gives them almost every capability they need except for
being able to include EAI recipients in that message. They certainly aren't
forced to use ASCII. We solved that problem 20 years ago.

So this is actually the temporary case. And let's review the steps: The sender
sends an EAI message to 10 people, one of them bounces with a clear indication
of why and no confusing list of other recipients to sort through, they now
construct a non-EAI message for that one recipient, done.

But let's assume for the moment that were were actually able to implement your
proposed solution of rejecting all recipients. (We cannot possibly do that, but
let's suppose.) Now what?

The sender is actually left in a much worse place. They send a message to 10
recipients, they get back an error that they have to read very, very carefully
in order to figure out what to do next. (In my experience the chances of most
users doing this are nil.)

Now the sender either has to one version of the message to the 9 EAI
recipients, which in many UI is a major pain, and send another to the remaining
recipient. This is exactly the same result they would have gotten from how
things are defined to work now, except the sender and not the system had to do
all the work.

The alternative is to try and figure out non-EAI addresses for the 9 others,
which may well be impossible, in order to send a non-EAI message to all 10.
This is far beyond the capacity of most people to do.

> I think that most users can bear the temporary failure of message delivery,
> but is unlikely to bear the permanent failure of message delivery.

That's not really true, but if it were you've just excluded your own proposal
from consideration.

				Ned

---

From: Tony Finch <[email-masked]>
Date: Wed, 7 Mar 2012 13:53:02 +0000

> last reply to the EAI list.)

... snipped ...

I've been talking to John Levine about this. I have a concrete application
in mind which is a web <-> DNS UPDATE gateway ...

> draft-levine-dnsextlang-02.txt. He went through the entire list of
> previously defined RRTYPEs to come up with a list of all the binary data
> formats and their associated presentation format in standard zone files
> that are used in DNS records. [...] It turns out the list is actually
> pretty short: integers (1, 2, or 4 bytes), IPv4 and IPv6 addresses,
> domain names (compressed or uncompressed, qualified by whether or not
> the server should fetch associated A records), stirngs (short, long,
> multiple), base64 (counted or uncounted), and hex. That's it.

Sadly there are a few RR types which are a bit more complicated, and not
all of them can be ignored. LOC, APL, IPSECKEY, HIP.

I would quite like to be able to use John's language to be able to
translate back and forth between wire format and master file format for
all RR types including the baroque DNSSEC ones - though that will need
some type-specific code - as well as being able to auto-generate a user
interface for the simple cases and future types.

> and presentation formats, in part to be able to make a legitimate claim to

IPSECKEY RRs are a counterexample. Really it should have been three RR
types, sigh.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, West Dogger: Westerly 5 to 7, perhaps gale 8
later in Cromarty. Moderate or rough, occasionally very rough in Forties.
Wintry showers. Good.