Re: [EAI] Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd)

[John C Klensin <klensin at jck.com>]

--On Thursday, 08 March, 2007 17:59 +0200 Kari Hurtta
<hurtta+gmane at siilo.fmi.fi> wrote:

> "Charles Lindsey" <chl at clerew.man.ac.uk> writes
> in gmane.ietf.ima:
> 
>> On Thu, 08 Mar 2007 03:18:26 -0000, John C Klensin
>> <klensin at jck.com> wrote:
>> 
>> > 
>> > As mentioned above, "mail storage agent" is not
>> > well-defined or formally part of the model
>> > 
>> >> cannot safely assume that agents accessing email storage
>> > 
>> > It is a little worse than that.  It may use some protocol --
>> > either LMTP or something that is not standardized in the
>> >...

>> If a server advertises UTF8SMTP, then it is ofering a
>> guarantee:
>> 
>>     "Either I will ensure that this messages is handed off,
>>     in exactly the  form received, to some
>> user/mailbox/store/system/whatever that is willing  to offer
>> essentially the same guarantee; OR I will downgrade it before
>>     passing it to any
>> user/mailbox/store/system/whatever that cannot give that
>> guarantee; OR I will send it back up the Return-Path with an
>>     explanation that it  could not be delivered."

ok.  But, for the case that Jari was concerned about, the second
option is eliminated since it cannot be guaranteed that
downgrading and subsequent reading by a legacy system will not
lose any information.  So the statement above is equivalent to
	"Unless I can pass the message into a mechanism or
	repository that guarantees full UTF8SMTP support, I must
	reject or return (bounce) it".  
For those of us who don't think highly of returning (bouncing)
messages, that is in turn almost equivalent to:
		"If a delivery MTA cannot guarantee that it can deliver
		the message to an UTF8SMTP-capable system, it SHOULD NOT
		advertise the SMTP extension at all"

I don't think one wants to go there, but they are certainly
options that, if I were implementing such an MTA, I would make
configurable.   They are, after all, just another set of points
in the tradeoffs between "deliver a message, even damaged,
whenever possible" and "deliver only those messages whose
integrity can be completely guaranteed".  

>> This implies, to me, that even if there are internal
>> communications (LMPT,  porocmail scripts, whatever) for
>> routeing mail for different local-parts  through different
>> channels, the MTA itself needs to be configured with  basic
>> information as to which local-parts/channels can offer the
>> UTF8SMTP  capability. Sounds like a case for a bit of
>> sendmail.cf hacking :-( .

In the most general cases, the MTA can't possibly know enough.
Worse, things can happen after "final delivery" over which the
MTA has no control.  For example, I would expect that, over
time, mail stores would migrate from 7-bit-only to
8-bit-capable, not only in content and headers, but in keys,
etc.  I would not expect them to migrate the other way, but see
no way to ban that.   So, just as a given message in a mail
store might be accessed by clients and user agents with a wide
variety of different capabilities, there is no way for the MTA
to know the behavior and capabilities, over time, of the message
destination.

> On stronger form that  user/mailbox/store/system/whatever
> system is arranged that way that non UTF8SMTP agents no not
> see UTF8SMTP messages.

By "not see" you mean, perhaps, "be told that they aren't
there?", "be told that they are not in a readable format?".
Note that we've already got provisions for the cases that do
work in the IMAP and POP documents, but, if a message is
delivered to a mail store or mechanism that is, itself,
UTF8SMTP-capable, but that store is accessed with a legacy POP
server, things may happen that are not predictable (since they
depend a lot on how the mail store and POP server are
implemented) or standardizable by this WG.

> For local delivery agent (LDA) that means that UTF8SMTP and
> ASCII messages are stored to different mailbox (files or
> directories or whatever).

One could implement it that way.  One could also implement it in
a variety of other ways.   Note that, if I have a mailbox for
which I have established several names (by aliasing or
otherwise), some of which involve non-ASCII addresses, and that
mailbox is fully UTF8SMTP-capable, I would consider the
restriction implied by the above completely unacceptable.

So I think you are talking about a whole series of
implementation or configuration choices above.  They are choices
I think our specifications should permit (even when I think they
would be dumb).  But, unless one of you is actually suggesting
standardizing something, I don't see where this discussion takes
us.  And, if you are suggesting standardizing something, let's
see the I-D.

     john


_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima