At 12:06 PM 4/23/2001 +1300, you wrote:
>The authors of TheBat! suggest above that this problem should not be
>their concern because the message should never arrive in such a state
>as it is clearly not standards-compliant. The same could be said of
>the Outlook/OE date header problem which, IIRC, required an
>unfeasibly long timezone value. "Unfeasible" how? Unfeasible
>according to the SMTP STD which effectively defined a maximum length
>for the Date: header's value of 30-something characters (I don't have
>the notes I made at the time and can't be bothered checking but it
>was well short of the length needed in just in the TZ part of the
>header to trigger the overflow).
>
>Sure overflows are bad and undesirable (they reflect something about
>the general levl of quality and security consciousness of the
>programmers if nothing else), but is not the real problem here that
>SMTP servers accept non-compliant messages in the first place **and
>pass them on thus**?
>
>Rather than pouring scorn on MS for the crappiness of the Outlook/OE
>date-parsing code as if they were the "real villians" in that case,
>shouldn't we have been pouring the scorn on the authors of the
>non-standards compliant servers that pass these messages?
I was under the impression that if a message did not adhere to the
standards, behaviour was _undefined_ rather than defined as to reject
it. Am I wrong? If not, then what the servers do with the message
(including passing it along to the mail clients) is fine.
Programs should not crash or allow security violations when presented with
unexpected input. So while the SMTP servers probably shouldn't be passing
along these messages, nor should the email clients be crashing.
