Subject: [Extra] New Version Notification for draft-bosch-sieve-eai-01.txt

From: Stephan Bosch <[email-masked]>
Date: Tue, 25 May 2021 21:28:14 +0200

Hi,

This is just a refresh of the document submission. Apart from my address 
information, nothing changed.

-------- Forwarded Message --------

A new version of I-D, draft-bosch-sieve-eai-01.txt
has been successfully submitted by Stephan Bosch and posted to the
IETF repository.

Name:		draft-bosch-sieve-eai
Revision:	01
Title:		Sieve: Internationalized Email
Document date:	2021-05-25
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/archive/id/draft-bosch-sieve-eai-01.txt
Status:         https://datatracker.ietf.org/doc/draft-bosch-sieve-eai/
Html: 
https://www.ietf.org/archive/id/draft-bosch-sieve-eai-01.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bosch-sieve-eai
Diff:           https://www.ietf.org/rfcdiff?url2=draft-bosch-sieve-eai-01

Abstract:
    This document defines an extension to the Sieve language called "eai"
    which adds full support for internationalized email.

The IETF Secretariat

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 26 May 2021 22:53:54 +1000

Awesome.  Are you planning to progress this document further?  I was about to email the list to see if there's interest in meeting at IETF111, and that probably depends if we have any work to do :)

Cheers,

Bron.

On Wed, May 26, 2021, at 05:28, Stephan Bosch wrote:
> _______________________________________________
> Extra mailing list
> [email-masked] <mailto:Extra%40ietf.org>
> https://www.ietf.org/mailman/listinfo/extra
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Ned Freed <[email-masked]>
Date: Wed, 26 May 2021 06:27:02 -0700 (PDT)

I'm afraid this document has a lot of probems, some of which may not be easy to
resolve.

The biggest problem by far is that the idea of invoking an extension in order to
be able to process an EAI message is intrinsicly nonsensical: A message
presented to the Sieve interpreter is either an EAI message or it's not, and
there's nothing the Sieve interpreter or Sieve author can do to change that. (It
may not even know if a given message was intended to be in EAI format - there's
no reliable marker for this.)

And now things start to get sticky: There's no telling what will happen if you
feed an EAI message into a Sieve implementation that's not itself EAI aware.
Will it simply process the UTF-8 it finds by leaving it alone (likely)? Or will
it treat the UTF-8 it finds in headers as illegal - whatever that means? Will it
know that message/global contains a message, and if so, will it be able to look
inside of an encoded message/global (probably not)?

The ineluctable conclusion here is that an email system that supports both EAI
and Sieve in a compliant way MUST support EAI in Sieve. This is a compliance
matter, plain and simple, and cannot be handled as an extension. So the first
task of this document needs to be to define what this form of compliance means.
It definitely includes saying that the header and address tests must allow for
unencoded UTF-8, proper handling of message/global, and probably a bunch of
other stuff.

But now things get even stickier: A-labels. EAI extends the message format to
allow, among other things, U-Labels in domains, but AFAIK doesn't explicitly say
that A-Labels cannot be used. (Except in the case of domains in trace fields,
and as a recent discussion has shown, it appears this requirement is being
widely ignored.)

Domains appear in a lot more header fields than addresses, and it would be
asking a lot of a Sieve implementation to know how to parse them all and convert
A-labels to U-labels. FWIW, I think the right answer is to only perform the
conversion in the address test, but I could be persuaded  otherwise.

Redirect, vacation, notify, and any other action that sends a message are where
an smtputf8, as opposed to an eai, Sieve extension makes sense. And note that
all of these actions can send an EAI even if the original message wasn't EAI.

A careful review of every Sieve extension with an eye to how it interacts
with EAI needs to be done, but that should be deferred until we're settled
on the overall approach.

Finally, I note that there's some odd language in the current document
about not interpreting encoded-words in EAI messages. This makes no sense
to me as messsages are often Frankensteinian in origin and can easily
end up with a mix of UTF-8 and encoded-words.

				Ned

> [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 26 May 2021 22:23:27 -0400

It appears that Ned Freed  <[email-masked]> said:
>no reliable marker for this.) ...

Yup.  I think it might be possible to redo this draft as advice on what a sieve
implementation has to do to handle EAI mail, but your sieve code either handles
EAI mail, in which case it makes sense to let it process EAI messages, or it
doesn't, so the behavior with EAI messages is undefined.

R's,
John