Re: utf8 messages

On 2014-08-15 17:15, Daniel Vargha wrote:
>
> On 15/08/2014 15:13, "Ned Freed" <[email protected]> wrote:
>
>>> On 14/08/2014 01:56, "Ned Freed" <[email protected]> wrote:
>>
>>>>> I fully agree with Brandon, the standard SHOULD consider the use case
>>>>> when a
>>>>> message is transferred from one system to another as a blob (e.g.
>>> flat
>>>>> file) and
>>>>> the only available "metadata" is that the message is in MIME format.
>>>>> Having
>>>>> some sort of well defined UTF8 indicator in the header section of the
>>>>> message
>>>>> would make it much simpler to adopt the new standard as it would
>>> require
>>>>> substantially less development effort in most cases.
>>>>
>>>> I'm skeptical of the claim, but if you absolutely have to have
>>> something,
>>>> why
>>>> not add a Received: field containing a "with smtputf8" clause, assuming
>>>> one
>>>> isn't there already?
>>
>>> Received: headers are not very reliable, and the syntax is is not well
>>> defined.
>>
>> On the contrary, it's quite well defined. See RFC 5321. The issue isn't
>> that
>> it's poorly defined, but rather that there are a lot of agents that don't
>> create it properly.
>
> Maybe because it was defined too late, and not in the right place? (RFC
> 5321
> is about SMTP not about MIME) From the parser's point of view the reason
> is
> indifferent, the reality is that it is better not to rely on it. Even RFC
> 5321
> says:
>
> "...receiving systems MUST NOT reject mail based on the format of a trace
> header field and SHOULD be extremely robust in the light of unexpected
> information or formats in those header fields."
>
>>
>>> Successfully parsing a Received: header itself requires a lot of
>>> heuristics.
>>
>> A full parse does, and so does looking for IP address information (which
>> doesn't appear directly as a clause value and whose position was only
>> standardized late in the game). Looking for a with clause with a
>> particular
>> value does not.
>
> Looks like we have quite different ideas about reliability and parsing.
> I certainly would not consider the partial parsing approach you suggested
> as reliable.

It's only the topmost (last added) Received header field that is
to be considered here. It is added by your own mailer, and you
know exactly what software that is using. The topmost added
Received header field is always in the same format, its contents
is always trustworthy. It is likely RFC 5321 compliant, but even
if it is not, you already know and can rely on its idiosyncrasies.
So there is no good excuse for not fetching the WITH clause
from this field, if other ways of accessing the EAI flag are
not available.

   Mark

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822