Standards track vs. downgrade

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

+1

>  The additional information intended to reverse downgrading I think isn’t helpful (like the downgraded headers), since, by definition, the recipient doesn’t >know about EAI and won’t know what to do with it.  

+1

>Only rarely would a downgraded message end up somewhere that reversal is interesting and I don’t
>think that’s worth the complexity and difficulties.

simple will work.

>
> Is there anything blocking one-way downgrade from standards track?
>

It depends on WG  to do the choice: how much downgrade we need.

other factors we may consider are:
1. which method is easy to be implemented and deployed?
2. which method will survive 10 or 20 or more years?
3. which method will cause less internet security?
4. which method is more convenient to internet email users?
5. we can not be too optimistic to pridict that all the email servers will be updated to support  EAI in the long run. There will always have some servers to refuse to update.


Yao Jiankang
CNNIC

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Shawn Steele wrote: Fully agreed. The completely central and essential point is (in my
opinion) what mechanism we use to bring the ASCII address from the
sender to the downgrading point. Everything else is details.

(rest of message snipped in the interest of brevity)

                   Harald


_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

--On Monday, August 17, 2009 18:20 +0000 Shawn Steele
<Shawn.Steele@...> wrote:

Shawn,

The WG went over the sort of approach you are suggesting and
concluded it was a bad idea.  While the decision may be worth
reviewing, there were concerns about reconstruction of original
messages and addresses by EAI-aware MUAs that were being used
"behind" EAI-unaware servers, possibly including MUAs that had
access to EAI-aware submission servers even if they could not
directly receive i18n-email.   Note too that the
security-related issues of pairing email addresses get a bit
worse if the address-switching process (downgrading) doesn't
leave very clear traces.  In principle, those traces could be
left in more extensive Received fields rather than Downgraded
headers, but, at least to my knowledge, no one has worked
through those cases to a successful proposal.

At this stage, and speaking just for myself, I'd give you a
different sort of answer:  In order to get the forward
downgrading that you suggest, one still has to make a disruptive
change to email syntax and one still has to extend the basic
email model to include the notion of "if this address doesn't
work, try that one".  Even if addresses are substituted, one has
to be able to convert UTF-8 headers to an ASCII-compatible form.
And one has to do so only for those cases in which all non-ASCII
addresses have alternate addresses specified.  In addition, all
of the relevant cases --with the possible exception of the
still-underexplored mailing lists-- are going to be the result
of oddities (such as EAI-compliant MUAs behind EAI-unaware
delivery servers) or configuration errors.

That is, IMO, a pretty high price to pay for a fairly marginal
facility.   The price becomes more acceptable, at least from my
perspective, if we can deliver high value, such as downgraded
messages with little or no information loss, by paying it (the
belief that we could deliver that value is why I've been
supportive of downgrading all along).   But, if we strip
downgrading as much as possible, accept significant information
loss as your proposal would imply, etc., then my instinct is
that we should drop all of these mechanisms as simply not
necessary enough to justify the costs.

Remember that there is an obvious forward downgrade mechanism
that doesn't require IETF protocol work.  It works like this
(with apologies to Yao, who has been advocating a similar idea):

(1) The implementation of an EAI-aware Submission server keeps a
table of ASCII addresses corresponding to non-ASCII ones, both
backward-pointing (easy) and forward-pointing (the model for
populating the table is a little obscure, but not an IETF
problem).  

(2) When it sends a message onto the Internet that requires EAI
and uses the extensions, it makes sure that the
backward-pointing address (return-path) points to it and that it
can recognize it.  There are any number of ways to do that; none
of them require IETF protocol work.

(3) If, somewhere along the line, the EAI extension is not
offered, the transaction gets rejected.  The submission server
either figures out that the rejection occurred in SMTP
processing or it gets an error reply message which it recognizes.

(4) If the EAI transaction is rejected and reported as above,
the Submission server rewrites the message to use all-ASCII
addresses and headers and resends it.  Presto! Downgrading.  It
can notify the sender that the original message didn't go
through, etc.

(5) Note that this model also offers an option that the current
Downgrade model does not.  With the Downgrade model, if any
non-ASCII addresses cannot be downgraded, the message must be
bounced, presumably to a Submission server and submitting
user/MUA who have no idea what to do with it.  If the machinery
outlined above exists in the Submission server, then it would be
perfectly reasonable to have the Submission server contact the
submitting user/MUA, or even have configuration options about
what to do if some addresses are undeliverable (such as
selectively notifying the sender that the recipient list had
been trimmed).  That conversation would permit delivery to all
downgradable addresses if the sender wanted to do that, or
reformulation of the message, or anything else desired by the
sender.

> Is there anything blocking one-way downgrade from standards
> track?

IMO, the fact that it would be a bad idea and that it doesn't
deliver enough value for the cost.  But YMMD.

   john

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

> At this stage, and speaking just for myself, I'd give you a
> different sort of answer:  In order to get the forward
> downgrading that you suggest, one still has to make a disruptive
> change to email syntax and one still has to extend the basic
> email model to include the notion of "if this address doesn't
> work, try that one".

I don't think that matters.  If I have an EAI-aware client trying to send mail (or server connecting to another server), then it'll get downgraded.  Certainly the client would be able to know about the 2 addresses when sending the mail, and an EAI aware server should be able to understand the necessary syntax <Unicode<ASCII>> or whatever to convert to ASCII.

Going back pretty much is a non-issue since the reply would be all-ASCII, which should continue to work.

> That is, IMO, a pretty high price to pay for a fairly marginal
> facility.   The price becomes more acceptable, at least from my
> perspective, if we can deliver high value, such as downgraded
> messages with little or no information loss

I think that no information loss has been demonstrated to be impossible.  The downgraded headers fail in some cases, or trigger more spam detection, etc.  Any change would probably be similarly disruptive.  Certainly any modified/new header would probably break some legacy client.  Another mime-part/type with the downgrade as a block might help, but then it'll probably just get clipped or rejected by other clients.

So IMO if a message is downgraded, it must end up looking like a legacy message.  Any interesting deviation would break the expectations of some systems.

> (1) The implementation of an EAI-aware Submission server keeps a
> table of ASCII addresses corresponding to non-ASCII ones, both
> backward-pointing (easy) and forward-pointing (the model for
> populating the table is a little obscure, but not an IETF
> problem).

That's sort of what I'm calling downgrade.  I'm not sure which way you're calling backward & forward, but one direction isn't necessary, as replies would just use ASCII aliases for the UTF-8 accounts.  (Most modern servers allow multiple addresses for a single mailbox, so this is just a management tool issue for a server that understands UTF-8).

I'm not really sure we're disagreeing here.

> (2) When it sends a message onto the Internet that requires EAI
> and uses the extensions, it makes sure that the
> backward-pointing address (return-path) points to it and that it
> can recognize it.  There are any number of ways to do that; none
> of them require IETF protocol work.

Eg: If I send it through my server, my server sends it out as an ASCII alias that it recognizes for my mailbox.  The one question I'm curious about would be if I send mail through another server, then my mail client would have to provide that connection.

> (3) If, somewhere along the line, the EAI extension is not
> offered, the transaction gets rejected.  The submission server
> either figures out that the rejection occurred in SMTP
> processing or it gets an error reply message which it recognizes.

In practice, I'd expect either the sending end or the receiving end to understand EAI.  I think it's unlikely that a message makes it to a gateway that understood EAI but didn't know about the sender's user account.  I don't think that <Unicode<ASCII>> or other syntax is disruptive in that case since any EAI aware server should understand it.

> (4) If the EAI transaction is rejected and reported as above,
> the Submission server rewrites the message to use all-ASCII
> addresses and headers and resends it.  Presto! Downgrading.  It
> can notify the sender that the original message didn't go
> through, etc.

Yes, and that's what I'm calling minimal downgrade :)  I wouldn't bother with notification though, but that's my opinion.

> (5) Note that this model also offers an option that the current
> Downgrade model does not.  With the Downgrade model, if any
> non-ASCII addresses cannot be downgraded, the message must be
> bounced, presumably to a Submission server and submitting
> user/MUA who have no idea what to do with it.

I don't think we're very far apart.  I'd say the submission server & submission client should be able to handle downgrade.  I do think it'd be worth forwarding a minimal amount of information as well in case an intermediate server needs to downgrade.  I don't think that'd be disruptive or expensive.

-Shawn
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima