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$1@xxxxxxxxxxxxx> 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 IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf