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

[Ned Freed <[e-mail]>]

> > 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.

> Yes, that is all true and I agree. But wouldn't it also be necessary to
> know whether the script author is expecting message/global messages?

I don't see why. Sieve interpreters by default decode encoded words and
translate them to UTF-8, which effectively changes the message format from
message/rfc822 to message/global. The one place where UTF-8 can occur that it
couldn't previously is in addresses and domains, but since you can already
compare UTF-8 strings to addresses and domain in Sieve (they won't match but
won't produce an error), and variables can contain UTF-8 values, I'm not seeing
a reason why there's any need for an extension to announce this.

And perhaps more to the point, what's an interpreter supposed to do with an EAI
message when the script says it can't handle it? Downgrade? We've tried twice to
define a viable downgrade format, and I can pretty much guarantee that use of
either one is a cure that's much worse than the disease. I for one would not
even consider implementing such a thing.

> The
> eai extension would indicate that the script was written with the
> possibility of receiving message/global in mind.

And therein lies the problem. Given the way Sieve is defined the overwhelming 
majority of scripts will work fine with EAI messages. (Weren't we clever?) Your
proposal, taken to the logical conclusion, will penalize all of those scripts
for the sake of a few edge cases.

> I haven't read the
> relevant RFCs in a while (and not going to right now), but what is
> supposed to happen when the server has EAI support but the mail
> retrieval agent (IMAP client) does not?

You either deny access or downgrade, although in practice I suspect "just send
EAI" happens a lot.

> I remember something about
> downgrade or placeholder messages. Most solutions I'd imagine would be
> far from ideal.

Yes they are.

> The most crude solution could be to make the recipient
> server reject message/global outright when it somehow knows the
> destination user doesn't have the software installed to read the
> messages. Our software doesn't do much of the EAI stuff yet, so I can't
> say I have implementation/deployment experience. My point is: forcing
> Sieve scripts to handle EAI messages when they were not written with
> such messages in mind could pose problems. What to do? I don't know...

Well, I *can* speak from experience. Making an MTA EAI-aware in a way that
actually provides a somewhat satisfactory experience is a real PITA, because you
have to figure out *why* the message was marked as EAI in order to hanle it
optimally.

IMAP is also difficult because of the downgrade issue.

In contrast, converting our core Sieve interpreter to support EAI was easy. It's
entirely a matter of how you handle previously illegal 8bit in a few contexts. 
You probably already have code for that - and if you don't and are passing 8bit
through unchanged it will mostly work - so that's where the changes go.

> Also, the ManageSieve client would need to know somehow that EAI is
> supported by the server. It could connect to IMAP first and find out,
> but I think that is not the way to handle this. Of course this could be
> a ManageSieve capability then and not a Sieve extension.

Again, I don't see why. If there's no EAI extension there's nothing
to detect. An smtputf8 extension is another matter, of course.

> > 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.

> I'd say all Sieve bits that compare addresses (address test, vacation
> :addresses etc.) or domains should normalize them in several ways,
> including the A-label/U-label format.

Much as I wish it were otherwise, there's no defined normalization for
local-parts, so applying a default normalization may actually produce bogus
results. The good news is Sieve supports comparators, and comparators can
specify normalization, including on the address test. Not ideal, but given how
EAI is defined, I don't know what else could be done.

				Ned