Subject: [IMA] ALT address - Round 2

From: yangwoo ko <[email-masked]>
Date: Wed, 03 Aug 2005 22:15:52 +0900

Dear John,

One point is not yet clear to me. An ALT-address in
your draft has a loose (or user level) relationship
with the corresponding TO-address. Users will have
at least two addresses. One is in his/her native
script and is for communication with others
using/understanding/being-able-to-use the same script
given that the mail infrastructure supports it. Another
one is in all ASCII and is for fallback or for
communication with others not-using/not-understading
/not-currently-being-able-to-use the script.

We may let users to use either of the two depending
on the situation.

If that is the case, I don't quite understand why
we need to have ALT-address fields at all.

Regards

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Aug 2005 10:12:30 -0400

> We may let users to use either of the two depending

I would have said, instead, “the user may use either of the 
two depending on the situation”.  I think it is important to 
stress that this is a user decision.

> we need to have ALT-address fields at all.

In principle, you don’t.  Whether or not we want to permit 
them depends on whether you want automatic downgrading to be 
possible in the event that, for example, the target machine 
(with known IMA capability) is configured (incorrectly?) with a 
relay host that does not support IMA.  If you presume:

	* A user with IMA support in her MUA and the associated
	first-hop (submission) MTA.  Presumably, an IMA user can
	select the first-hop MTA so that it is IMA-capable and
	would want to do so.
	
	* A receiving/delivery system with IMA support.
	
	* All fallback or other intermediary MX hosts for the
	receiving / delivery system have IMA support.
	Presumably the choice of lower-preference MX hosts is
	under the control of the operators of the receiving
	system and they would prefer hosts that are as capable
	as they are (not only for IMA but for other SMTP
	extensions)

Then one does not need alternate addresses and a great deal of 
implementation complexity is avoided.   I would caution that, 
for many reasons, the above list of assumptions and presumptions 
may not be met in some cases.  For those cases, mail that starts 
with forward- or backward-pointing IMA addresses in it is likely 
to be bounced as undeliverable (or, if the anti-spammers are 
involved, even worse things may occur).   However, given the 
amount of complexity that would be saved, if we concluded that 
the cases were not numerous initially and would become fewer, it 
might be best to drop alternate addresses.

If nothing else, that line of discussion might justify a “MAY 
implement downgrading and alternate address support” rather 
than a “SHOULD” or even “MUST” statement.

Again, there are some odd cases here that I haven’t analyzed. 
For example, if we have a message that, internally, is
    From: ascii-address@host
    To:  ima-address@ima-capable-host,
          ascii-address@host2
and the first hop is IMA-capable, then the second (delivery if 
there are no MX relays) hop envelopes will include

    RCPT TO:<ima-address@ima-capable-host>
(going over a connection to that host only) and

    RCPT TO:<ascii-address@host2>
(going over a connection to that host only)

This is fine, except that, in the second case, we’ve got some 
issues about what the mail headers are supposed to look like 
and/or whether encapsulation should occur.

This type of situation, and the even more complex one involving 
mailing lists containing both traditional-style and IMA-style 
addresses, are examples of what I was talking about yesterday 
when I suggested that one of the difficult and time-consuming 
activities in developing a protocol in this area will involve 
identifying all of these cases and making sure that a given 
solution works (or we have an appropriate solution) for it.

Note that “what happens to the headers” for a 
multiple-recipient message is quite important because there are 
many things that make it desirable for all recipients to 
receive, in some form, identical headers.  In addition, anything 
that involves signed headers or header components (such as 
several of the anti-spam proposals) is going to require _very_ 
careful handling of anything that alters headers in any way.

To repeat what I said yesterday, I think this can be done.  I am 
quite optimistic that it can be done well, without limiting 
email capabilities as the price of internationalization.  But we 
have some serious hard work ahead of us, not just a little bit 
of quick protocol design.

regards,
       john