Downgrade Design Team Discussion Results IETF 77 DDT

The EAI Downgrade Design Team (DDT) was created to investigate the problems around EAI downgrade. DDT examines the results of the current downgrade experiment and the discussion and suggestions of the EAI working group. DDT grouped the possible approaches to backwards legacy SMTP compatibility into three buckets:

1) Declared address pairs, eg: Alt-Addr. This is the approach described in RFC5504 (downgrade) and variations on it.

2) Discoverable fallback address. – This includes any MUA/submission server protocol that derives ASCII addresses from a Unicode address for resubmission by legacy SMTP. – It also includes other algorithmic techniques, lookup of alternate addresses in local address books, and those using protocols external to SMTP processing to find those addresses. – The key characteristic of this bucket is that there is no downgrading of messages in transit; changes to addresses or other information are made only at the originating MUA or submission server, typically in response to external knowledge or some information received by them such as an NDN. – This bucket does not require Alt-Addr parameters, header address syntax to support them, or other dependencies on legacy compatibility strategies in the core transmission protocols.

3) No fallback. This devolves into "messages with undeliverable addresses are rejected", i.e., the traditional SMTP model. A user, or programs acting on the user's behalf, can, of course, alter or resubmit the message with different address information.

Declared address pairs (e.g., with Alt- Addr) have been ruled out as a possible solution. – The RFC5504 experiment was invaluable in revealing the limitations of a paired address system. – The Design Team concludes that paired address mechanisms are inherently fragile. The pairing has innate problems with lost pairs, mismatched pairs, possible spoofing, and failure in some cases. – Additionally, the extensions provided by RFC5504 cause problems for some legacy mail systems.

Discoverable fallback address mechanisms are potentially interesting because they can always be determined by systems aware of the discoverability convention. – However, discoverable fallback address mechanisms do not require Alt-Addr and do not have to be visible in the core documents. – There has been a lot of discussion about the practicality of the proposed mechanisms for discoverable fallback; we expect that those discussions will continue, but that they will do so outside the critical path. – In theory, discoverable fallback addresses could be discovered by a relay server rather than at the MUA/submission server. This approach was deemed impractical; it requires too much coordination between parties that do not have communication with each other.

No fallback is a technically "simple" solution. It also does not require Alt-Addr and requires no consideration in the core documents. The submission server may still resubmit using SMTP if available.

By ruling out "declared address pairs" solutions as impractical, and by removing any support for "downgrading at relays", we remove the dependency of the core documents on specific downgrade models. This allows further progress on the core documents by the working group.

In conclusion, the EAI Downgrade Design Team recommends: – o That we immediately recharter EAI to focus on the core standards track documents, i.e., RFC4952bis, RFC5335bis, RFC5336bis, RFC5337bis, RFC5721bis, and the in-progress drafts. – o RFC5504 should be deprecated. The core documents will not rely on fallback or downgrade techniques, particularly by relays. – o Discoverable fallback addresses may be investigated independently of the core documents. Any such work would be part of, or connected to, an optional MUA/submission protocol, independent of the core transport documents.

The design team also noted that an informational RFC regarding selection of addresses (both Unicode and ASCII) would be helpful, that clients SHOULD use Unicode Normalization Form C, and that servers MUST use NFC.