|
»
The value of simplified downgrade
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
The value of simplified downgrade
by Ernie Dainow
::
Rate this Message:
There is a question of whether the EAI spec should include simplified
downgrade at all. To help answer this, compare what a user has to do in various situations when there is downgrade and when there is not. From the user's point of view, there are not that many cases to consider. 1. Sending email to an EAI user ("sending" includes compose new mail, forward, reply). This case will not have downgrade. If any recipients cannot in fact receive EAI mail, it will bounce. This is being considered a 'configuration' error. Note this is different from the current Downgrade spec which supports downgrade to forward pointing addresses. 2. Sending email to an non-EAI user. a. If EAI has downgrade, the user may use his EAI email account. As long as an alternate address has been configured, the mail will be downgraded using the supplied ASCII address as the From address. b. If there is no downgrade, the user will have to use his non-EAI email account. This is slightly awkward, but not be a major hindrance. Many people are used to managing more than one email accounts, for example one for work and a second for personal email. 3. Sending email to a mix of EAI and non-EAI users. a. If EAI has downgrade, the user may use his EAI email account and send a single message, freely mixing EAI and non-EAI addresses on To, Cc, etc. b. If there is no downgrade, the user will have to send the same email twice; once using the EAI account for the EAI recipients and a second time using the non-EAI account for the non-EAI recipients. Note that in 3b, EAI users and non-EAI recipients do not know the whole list of recipients, and Reply All will not reach the full list (unless the original sender is very disciplined and copies replies from EAI to non-EAI recipients and vice versa). By comparison, in 3a, EAI recipients will see all the people that received the email and Reply All will reach everyone. However, non-EAI recipients will not see any of the EAI recipients, and their Reply All will only reach the non-EAI recipients and the sender. This is a consequence of dropping double angle brackets on forward pointing addresses, and was pointed out by Harald as the "triangle" case. As noted in that discussion, even with double angle brackets the triangle case will not consistently work in practice, as it depends on users being sufficiently disciplined to undertake the extra effort of entering alterrnate addresses for all EAI email addresses. Clearly, the pain is case 3b. To the extent that we wish to improve on this scenario, we should include downgrade. A second consideration is the effect on encouraging and speeding the migration to EAI from legacy email systems. Without downgrade, people have to actively maintain two email accounts. Under this circumstance, they may just choose the non-EAI account as the primary. With downgrade, there is an incentive to use the EAI account as the primary account, since it handles mail for all cases 1, 2 and 3. One of the assumptions in a simplified downgrade is that it is not perfect (does not handle every possible case) and may lose some audit trail information. We need to decide if an imperfect downgrade is still better than no downgrade at all. -Ernie _______________________________________________ IMA mailing list IMA@... https://www.ietf.org/mailman/listinfo/ima |
|
|
|
|
|
Re: The value of simplified downgrade
by Ernie Dainow
::
Rate this Message:
Shawn Steele wrote: >> By comparison, in 3a, EAI recipients will see all the people that >> received the email and Reply All will reach everyone. However, non-EAI >> recipients will not see any of the EAI recipients, and their Reply All >> will only reach the non-EAI recipients and the sender. >> > > This summarizes my concerns with "partial" downgrade solutions. Things that appear to work stop working in edge cases, and it may be difficult for the sender to predict or understand the behavior. If it fails completely I know I need to get fixed addresses or get an updated mail client or whine at my network admin or something. If it fails "randomly" (many users won't recognize the pattern) then they have no recourse (but to whine at the network admin, which won't help but will cost the support people a lot of money.) > > In short: If it always works for me, great. If it's always broken, then I'll do something to fix it, but if it works sometimes but not others I just get confused and it gets expensive to support. > downgrade which was for a simplified but imperfect solution. Note that the 'full' downgrade specified in RFC 5504 does not meet this criterion either. Although RFC 5504, unlike the simplified downgrade, is able to handle the 'triangle' case, it will not be reliable and may work sometimes and not others. This is because Alternate Addresses are optional and not required. If the user does not provide an alternate address for every recipient EAI address, someone will be left out on a Reply All to a downgraded message. I don't think anyone would consider making Alternate Addesses required to solve this. So other approaches are necessary. On another thread (Thinking about requirements / downgrade), you have proposed to auto-generate alternate addresses to handle cases like this. That may provide a solution. Other approaches are possible. I think a cleaner one than an ACE based scheme is as follows. Have alternate addresses stored on the server, associated with the primary EAI address for the account (this has been recommended in draft-yao-eai-deployment, section 3). Then add a new SMTP command, something like VRFY, that verifies an email address and returns the associated alternate address. So when an MTA discovers it needs to downgrade, it can use this SMTP command to get the alternate addresses needed from an authoritative source. -Ernie _______________________________________________ IMA mailing list IMA@... https://www.ietf.org/mailman/listinfo/ima |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: The value of simplified downgrade
by Shawn Steele
::
Rate this Message:
I wasn't very clear, stuck on my cell phone, sorry.
I mean that if a user is trying to send To: and EAI address, and has an EAI aware client, it'd be nice if it could "downgrade" before it got to the server on the sending side. Then, even though the sender's mail server isn't an EAI server, they could still have a rich EAI experience. For example, the sender could be me in a US company that doesn't see a need for EAI mailboxes sending mail to a Japanese EAI address. I think that to be "complete" downgrade would need to consider that kind of scenario (downgrade from sender client before reaching sender server). That necessitates some sort of automatic mechanism for downgrade, since the sender may not have the ASCII address. So either algorithmic, or perhaps contacting the server hosting the EAI address. Due to port blocking, firewalls and proxies and all that, I'm skeptical that the information could be requested reliably from the host server. -Shawn -----Original Message----- From: SM [mailto:sm@...] Sent: Thursday, September 10, 2009 13:23 To: Shawn Steele Cc: ima@... Subject: RE: [EAI] The value of simplified downgrade At 11:16 10-09-2009, Shawn Steele wrote: >So you aren't suggesting an eai aware client should be able to >downgradw w/o an eai aware server on it's side? That is >unnecessarily restrictive. No, my comment was about not having a MUA interact with the SMTP server at the receiving end. I'll comment further in my reply to Ernie's message. Regards, -sm _______________________________________________ IMA mailing list IMA@... https://www.ietf.org/mailman/listinfo/ima |
|
|
Re: The value of simplified downgrade
by sm-7
::
Rate this Message:
Hi Ernie,
At 06:57 10-09-2009, Ernie Dainow wrote: >Have alternate addresses stored on the server, associated with the >primary EAI address for the account (this has been recommended in >draft-yao-eai-deployment, section 3). Then add a new SMTP command, >something like VRFY, that verifies an email address and returns the >associated alternate address. So when an MTA discovers it needs to >downgrade, it can use this SMTP command to get the alternate >addresses needed from an authoritative source. What Section 3 of draft-yao-eai-deployment-03 recommends is to generate an alternative address and have it stored on the (sender) server-side. The user does not have to bother about that alternative address as the server puts it in. Are you suggesting using VRFY to get the alternative address from another SMTP server? Regards, -sm _______________________________________________ IMA mailing list IMA@... https://www.ietf.org/mailman/listinfo/ima |
|
|
|
|
|
Re: The value of simplified downgrade
by John C Klensin-3
::
Rate this Message:
--On Saturday, September 12, 2009 00:06 +0800 Yao Jiankang <yaojk@...> wrote: >... >> 1. Sending email to an EAI user ("sending" includes compose >> new mail, forward, reply). >> This case will not have downgrade. If any recipients cannot >> in fact receive EAI mail, it will bounce. This is being >> considered a 'configuration' error. Note this is different >> from the current Downgrade spec which supports downgrade to >> forward pointing addresses. > > If it is ascii user sending message to EAI, there should have > a downgrade. If it an ASCII user (i.e., a user of an ASCII-only environment) sending a message to an EAI user, then there are only two possible cases: (i) The ASCII user has (or can easily obtain) an ASCII address for the EAI user and can use it in her MUA. In this case, the user is doing the "downgrade" and no "downgrade" in the protocol is necessary or even useful. (ii) The ASCII user does not have an ASCII address for the intended recipient. In this case, no downgrading mechanism that we could devise is going to be helpful -- the situation is hopeless and no message can be sent. Note that this is really no different from the traditional situation in which you want to send some one an email message but don't have an address or a way to guess one (or have only an address on an internal email system with no way to guess the mapping from your external environment, even if one exists). You are out of luck until and unless you can use some out-of-band mechanism to determine a usable address. > If the SMTP server or MUA has not been updated to support EAI, > the ascii user can not send the message to EAI account because > the SMTP server or MUA can not recognize the EAI and will > regard the EAI address as illegal one. This has been pointed > out in draft-yao-eai-problem-00.txt. Yes. And in several other places. >> 2. Sending email to an non-EAI user. >> a. If EAI has downgrade, the user may use his EAI email >> account. As long as an alternate address has been >> configured, the mail will be downgraded using the supplied >> ASCII address as the From address. b. If there is no >> downgrade, the user will have to use his non-EAI email >> account. This is slightly awkward, but not be a major >> hindrance. Many people are used to managing more than one >> email accounts, for example one for work and a second for >> personal email. But, if the user has both addresses available, and understands that the target address is not EAI, then the user can (and probably should) use his ASCII address as the "From:" address and backward-pointing envelope (MAIL FROM) address. If I were constructing an EAI-aware MUA with multiple identity support, I'd want to arrange it to support paired identities and to switch to the ASCII address if any or all of the outgoing addresses were ASCII. Note that this does not require any downgrade support in the protocol. >> 3. Sending email to a mix of EAI and non-EAI users. >> a. If EAI has downgrade, the user may use his EAI email >> account and send a single message, freely mixing EAI and >> non-EAI addresses on To, Cc, etc. Actually, no. The user must not only be able to mix those addresses, but must also have alternate addresses for all of the EAI ones. Otherwise, if downgrade is needed, it will fail and the message will be rejected. For the situation in which all of the possibly-needed alternate addresses are available, the sender has two choices, even if downgrade is included in the protocol: (i) Treat the message as all-ASCII, using the alternate addresses starting from the point of origin and encoding the i18n addresses, if desired, into name phrases or comments. (ii) Have out-of-band knowledge of the actual deliverability of the EAI addresses (as several people have pointed out, this is extremely likely if those addresses exist and everything is configured correctly). This case does not require that downgrade exist or be usable. (iii) Hope that downgrade not only exists in the protocol but that it will actually be used properly when needed by mid-path software. Any MUA that takes this course of action must, in practice, assume that it will fail and be prepared (in some way) to deal with message rejection because downgrade support is not a _required_ element of our protocols even today. It further needs to assume (or hope) that nothing will cause message rejection in a relay environment that requires returning an NDN and that the NDN will actually be generated and not discarded as an anti-blowback "feature". Note that the first two of these do not require Downgrade in the protocol and that the third is inherently unreliable. >> b. If there is no >> downgrade, the user will have to send the same email twice; >> once using the EAI account for the EAI recipients and a >> second time using the non-EAI account for the non-EAI >> recipients. >> >> Note that in 3b, EAI users and non-EAI recipients do not know >> the whole list of recipients, and Reply All will not reach >> the full list (unless the original sender is very >> disciplined and copies replies from EAI to non-EAI >> recipients and vice versa). >> >> By comparison, in 3a, EAI recipients will see all the people >> that received the email and Reply All will reach everyone. >> However, non-EAI recipients will not see any of the EAI >> recipients, and their Reply All will only reach the non-EAI >> recipients and the sender. This is a consequence of dropping >> double angle brackets on forward pointing addresses, and was >> pointed out by Harald as the "triangle" case. As noted in >> that discussion, even with double angle brackets the >> triangle case will not consistently work in practice, as it >> depends on users being sufficiently disciplined to undertake >> the extra effort of entering alterrnate addresses for all EAI >> email addresses. > > in 3a, > +1, it means that even if the current full downgrade mechanism > is used, > we still can not assure 100% downgrade since the alt-address > is depending on the user. That is correct. If if the alt-addresses are present, we still cannot assure 100% downgrade. Absent specific out-of-band knowledge about the receiving and intermediate systems, there are no circumstances in which downgrading is going to be 100% reliable (I think this is part of the point Shawn has been trying to make). Conversely, if one has that out of band knowledge, downgrading is not needed because all of the relevant adjustments can be made by the originating user or her MUA. > so in this sense, simple downgrade does not differ from much > the full downgrade. This is one of the situations that has caused me to want to see a protocol spec rather than more inherently-vague discussion in email. "Simple downgrade" may mean at least the following different things: (i) Downgrade for backward-pointing addresses only ("MAIL FROM" and "From:"), even if the double-angle-bracket syntax is used for the latter. (ii) Downgrade for backward-pointing _envelope_ addresses only, perhaps in combination with a multiple-valued From: field. Note that doing this would permit return of NDNs even when (or especially when) interpretation of the "From:" field linkages is uncertain. There may be other combinations. Note that the first risks leakage, etc., while the second sacrifices unambiguous Reply-ability to improved deliverability. >> Clearly, the pain is case 3b. To the extent that we wish to >> improve on this scenario, we should include downgrade. >> > > 3b, is really pain? > > it is similar to business card situation. > the chinese business card has two sides, english side and > chinese side. > english side is only for those who can not under stand > english; chinse side is for those who knows chinese. I'm not sure that analogy works, except that, if one finds a single non-Chinese speaker among the cards, one then decides to carry out the entire conversation in "English" in the hope that all of the Chinese speakers also understand English. That, again, leads to three cases: (i) All of the Chinese speakers do, in fact, speak English, all of the cards are turned to the English side, and the conversation is carried out in English. This is very similar to the "it just gets fixed by the sender (or sending MUA) to use nothing but ASCII addresses" case above; in-route downgrading is not needed. (ii) Some of the English speakers do not understand Chinese and some of the Chinese speakers do not understand English. In this case, the situation is hopeless without an intermediate _language_ translation function, whether everyone has an ASCII address or not. And, if not everyone has an ASCII address, delivery is impossible, without or without a downgrade capability. (iii) All of the Chinese speakers understand English, but some of them do not use two-sided cards. The English speaking sender, who does not speak Chinese, still has a way to use the Chinese outbound addresses for those users and does so _and_ no downgrading is needed en route (since it would fail if attempted because not all alt-addresses are present). Downgrade doesn't help with this case for that reason. And I suggest that it will be extremely rare in practice. >> A second consideration is the effect on encouraging and >> speeding the migration to EAI from legacy email systems. >> Without downgrade, people have to actively maintain two >> email accounts. No. Without downgrade they have to maintain two email _addresses_. Whether those addresses are aliases for the same account is a local matter -- remember that messages with non-ASCII body parts work (or not) regardless of EAI. >> Under this circumstance, they may just >> choose the non-EAI account as the primary. With downgrade, >> there is an incentive to use the EAI account as the primary >> account, since it handles mail for all cases 1, 2 and 3. Except when downgrade fails to work as expected because some intermediary rejects rather than downgrading, because there are other recipients who haven't supplied alternate addresses, etc. >> One of the assumptions in a simplified downgrade is that it >> is not perfect (does not handle every possible case) and may >> lose some audit trail information. We need to decide if an >> imperfect downgrade is still better than no downgrade at all. One of the assumptions in a non-simplified downgrade (i.e., 5504-conformant downgrading) is that it is not perfect and will not downgrade every possible case and may lose some audit trail information. From that perspective, the simplified and non-simplified cases are not much different. I think the questions are whether the simplified (and less complex) form still buys enough to be worth the trouble... even if we conclude that the full downgrade form is complex enough, and covers few enough realistic additional cases, to not be worth the trouble it requires. One of the key differences is that senders are always capable of knowing their own ASCII addresses (if those exist), but that we have no reliable and general mechanism for knowing those of all receivers. > +1, yes. the WG should decide it. I'm not quite sure how the WG does that. It is not clear to me that these discussions are converging. And, more important personally, I don't know how I would decide without a concrete proposal for "simplified downgrade" on the table, presumably as an I-D, so that I could really try to analyze the cases. john _______________________________________________ IMA mailing list IMA@... https://www.ietf.org/mailman/listinfo/ima |
|
|
Re: The value of simplified downgrade
by Ernie Dainow
::
Rate this Message:
SM wrote: > Hi Ernie, > At 06:57 10-09-2009, Ernie Dainow wrote: >> Have alternate addresses stored on the server, associated with the >> primary EAI address for the account (this has been recommended in >> draft-yao-eai-deployment, section 3). Then add a new SMTP command, >> something like VRFY, that verifies an email address and returns the >> associated alternate address. So when an MTA discovers it needs to >> downgrade, it can use this SMTP command to get the alternate >> addresses needed from an authoritative source. > > What Section 3 of draft-yao-eai-deployment-03 recommends is to > generate an alternative address and have it stored on the (sender) > server-side. The user does not have to bother about that alternative > address as the server puts it in. > > Are you suggesting using VRFY to get the alternative address from > another SMTP server? address, it can provide it in response to a new SMTP command from another EAI server. Apparently some similar ideas of doing this type of lookup, for example via LDAP, were explored early on and rejected. Doing this securely becomes complicated very quickly. > > Regards, > -sm _______________________________________________ IMA mailing list IMA@... https://www.ietf.org/mailman/listinfo/ima |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
