Re: Objection to Last Call - draft-ietf-eai-utf8headers-09.txt

["Frank Ellermann" <[e-mail]>]

Charles Lindsey wrote:

> none of the MUAs available to me allow manual tinkering with
> References (and, worse, the ietf archives don't show Message-ID
> headers at all)

From my POV <news://news.gmane.org/frqiuc$dr5$[e-mail]>
was still okay apart from my unnecessary (1) and (2) confusion,
same as <http://article.gmane.org/gmane.ietf.general/29670/raw>,
whatever happened was between the list and the IETF archive.

> I might not have had any problem with message/global if it had
> only been intended to be seen inside the "global sandbox". But,
> unfortunately it is expected to be passed around _outside_ that
> sandbox, on the presently deployed network and, in spite of
> some wishful thinking on the EAI WG, that just will not work 
> (as I showed).

I never really believed in the "sandbox" approach, any MIME type
can be the Content-Type of a message/rfc822, or a part of a MIME
multipart/*, if that's an image/x-never-heard-of, message/global,
or any other MIME object.  My MUA would hopefully treat them all
like an application/octet-stream, or IOW as "dunno", I can save
it as unidentified file, and maybe tackle it with a hex. editor
or similar.

OTOH nobody has a reason to send me any image/x-never-heard-of
or message/global in MIME parts.  Unless it is in a DSN, because
I originally sent an EAI message, and in that case my MUA should
know what a message/global is.  

What could go wrong is that somebody gets an EAI message/global,
and sends it as an "attachment" of a message/rfc822 to somebody
else.  Ideally the MUA could say "don't do this", but if MUAs
try to be smart it usually gets worse, I'm not optimistic that
this part of the "sandbox" approach works.

>> <http://thread.gmane.org/gmane.ietf.smtp/6678/focus=6697>
>> Highly recommended for reading, I dare not summarize it here.
 
> I have read that thread, and it is clear that Ned would take
> a very dim view of disobeying that "EXPRESSLY FORBIDDEN", 
> especially any attempt to do so on the existing network.

> It may, with hindsight, have been the wrong decision, but it
> is there and that is what lots of agents have implemented.

I don't see how existing software could have implemented any
special treatment of new unknown message/* subtypes, they can't
know what it is, they are forced to handle it as "dunno", no
matter what the CTE is.  Actually they should know what B64 or
QP is, and unpack the unknown object so far when the user wants
to save it as file.  And the B64 or QP case is limited to rare
cases where a message/global needs to make it over a 7bit hop.

Or the mentioned message/global "attachment" case, but that's
not better or worse than image/x-never-heard of.  Insisting on
"EXPRESSLY FORBIDDEN" would mean that the MUA of the receiver
refuses to unpack it when the user tries to save it as file.

I don't know what MUAs do with a B64 encoded message/unknown,
but the spec. clearly says "treat as application/octet-stream",
IMO refusing to unpack B64 (or QP) would be just stupid.

Of course MIME tries to avoid the situation, it is designed to
cause as less pain as possible for MIME unaware MUAs, i.e. old
MUAs with no idea what B64 or QP is.  Violating the "EXRESSLY
FORBIDDEN" can hurt MIME-unaware MUAs, users won't see as much
as possible of what's inside the message/global.

But "fixing" this by using application/message, where B64 and
QP is allowed, won't improve the result for MIME-unaware MUAs,
they still have no clue how to unpack it, and how to show the
hidden structure.  IMO the whole point of "EXPRESSLY FORBIDDEN"
is to have a visible internal structure for MIME-unaware MUAs,
users can then at least read any "internal" text/* etc. parts.

> It is already known that 3 widely used MTAs will not cope
> with it, and I am only aware of one (not so widely used)
> that will.

MTAs have no business to look into the body of a mail unless
they are gateways from say 8BITMIME to 7bit.  Whatever they do
today with an 8bit message/unknown in this situation, they'd
also do it with an 8bit message/global while they don't know
what it is.  If they can't handle an 8bit message/unknown they
also can't handle an 8bit message/global in this scenario, but
at this point the CTE is 8bit, not B64 or QP.  I don't see why
permitting QP or B64 makes it worse as it is.  The gateway is
broken, if it can't handle 8bit message/unknown it should not
have accepted it for delivery.

> EAI is trying to do far more than fix "Email Address I18N".

Yes, that is the part I don't like, EAI trying to do only EAI
is interesting enough for the experiment.

> There are two ways to fix (1). Either an application/message,
> or else insist the message/global is downgraded before 
> letting it loose on the current network

For the case with a MIME-unaware MUA application/message isn't
better.  For a broken gateway accepting 8bit message/unknown
without a clue what to do with it offering a general solution
not limited to message/global as application/message can help,
but it still requires to fix the broken gateway (in that case
to use B64 application/message subtype=global or similar).

The WG didn't like this idea, and limited to message/global
using B64 message/global has the same effect.  In both cases
the broken gateway has to be fixed.  No idea why EAI didn't
want a general solution.

For your other proposal, insist on downgrading message/global
at the UTF8SMTP to 8BITMIME gateway (before the hard case 7bit
enters the picture at the same or a later hop), I don't know...

When we talked about it IIRC we both agreed that MTAs still not
supporting 8BITMIME are anyway doomed.  I didn't look into any
downgrading draft for ages, the last state I know was not good.

>> Of course the security considerations need to be very clear.
>> B64 message/global is not designed for forward paths, it is
>> no ersatz-downgrading, it is a loophole for rare cases where
>> the alternative would be to drop DSNs.
 
> But that is NOT what the utf8headers draft says.

The MIME registration template does, sort of:
| 8-bit or binary content-transfer-encodings are recommended
| where permitted.

Well, this stuff could be clearer, it's spread over three drafts,
the point where message/global is explicitly required is in the
DSN draft, the point where it's implicity used in in the smtp-ext
UTF8SMTP draft (explaining reject vs. forward), and finally the
definition is in utf8headers.  

IMO pretending that other cases (neither UTF8SMTP nor DSN) are
"impossible" won't fly, those mad "attachments" are at least in
theory possible, no matter what the drafts say.  Adding a DON'T
somewhere is an idea, but I would not believe that it works to
get a real "message/global sandbox".

 Frank

_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf