-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, November 29, 2002, Nathan J. Yoder wrote...
JA>> It's almost this kind of thinking (no offence) that starts JA>> getting programs in trouble. I know mailto: URLs won't cause any JA>> halm (unless you do permit certain headers to be set), but saying JA>> "well, just let this one slip a little" just starts to promote JA>> bad coding, and hence security bugs. > This doesn't promote bad coding at all, especially in this case. In > fact, most IE holes have nothing to do with not following official > standards (usually a buffer overflow or something related to > security zones and scripting). The cases which are involve > proprietary extensions added by MS themselves, not an effort to > support ones in wide use made by other people. MS has bad coding > practice in general, regardless of context, so trying to point one > thing as being the result of it seems a bit silly. IE was maybe a bad case to point forward. Some of the original buffer over flows in MS's TCP stack could have been avoided if they had correctly followed the proper responses to what were sent to the stack for example. The correct responses are listed as part of the RFCs on such a topic... but those a ages old, and Microsoft (as you said) have many bad coding practises. > The "be lenient in what you accept, strict in what you send" is the > standard, widely accepted mentality for 99% software. I understand the logic behind the thinking, but having to apply that for all software, whatever field is bound to end up opening things up in some unknown ways. The software company I work for pretty much gave up trying to 'customize' things to work on certain systems (in particular Compaq's) even though they were popular because of the amount of hacking to the code that would be required just to 'make it work' with the 'common'. > If you've ever written server or certain client software you'll > realize that there are a) a lot of non-standard clients and servers > and b) you have to support them. I, in fact, do. Both web based mailing software (www.squirrelmail.org) and also accounting software (www.certiflexdimension.com). Sticking to RFCs (in the first example) means we can work with all server software. The only server that has ever produced any problems for us has been (oddly enough) a Microsoft mail server. All other aspects of the software *require* RFC compliance otherwise it'd just not work right. > I've encountered problems like this, thinking it was a bug in my > code, only to find out about some sort of non-compliant support I > needed to add to allow the software on the other end to function > properly (this is especially true on usenet). Also especially true when dealing with big vendors, or corporations that decide they like to have things their way. Sometimes it's just not viable to hack stuff up to get it to work. The reason RFCs are about is to make it so that people don't have to do that. > Apache is a great example of software needing to support > non-compliant clients (see > http://www.apacheweek.com/issues/01-03-02). I find it amusing again that it is Microsoft (in the "Under Development" section) broke things to a point that the Apache developers had to decide whether or not to break the RFCs themselves just to make their software work. > I wouldn't be surprised if The Bat! accepts messages which are > incorrectly encoded (like with MIME). It could be possible, although I've not seen a case yet :) > I didn't know this until now, but apparently that "be lenient ..." > saying is from the IETF according to that URL, meaning they > acknowledge its necessity. But TB! is being lenient with it. It could just flat out refuse the mailto: link, instead it is accepting the mailto: link, but stopping at the point it breaks RFCs (the space). JA>> Plus the mailto: is follow standard RFC guidelines on correctly JA>> formatted URLs (you won't find a single website that can be JA>> served with a space in it, the server will convert the names to JA>> %20). Break it, and you might end up causing all kinds of issues. > This isn't breaking *anything*. This is about accepting a > non-compliant input, not producing a non-compliant output. Okay, I miss-stated that then. The fact is, TB! is accepting the non-compliant input, but is producing the compliant output. This is what is being considered a 'bug', when it is in fact correct behaviour. > This case is also different than a url with spaces in that the HTTP > protocol relies on url having no spaces (because the space is used > to delimit a parameter that comes after it). With mailto it can > easily be interpreted without confusion. This is not to mention the > fact that the non-compliant mailto: is in such wide use that it's > become an unofficial standard (the RFC itself was made in 1998, > longer after it had already been in use). mailto: is in fact another URI, and hence is affected by all the rules of URLs. Which go in the format: <protocol>:<server/mailbox>?<parameters> Or something similar to that. JA>> Saying that other clients (OE in your reference) interpret the JA>> mailto: correctly is incorrect. RFCs say, you *must* convert the JA>> special characters to their hex equivalent. Reading it in any JA>> other ways is wrong, no matter how you look at it. > It may be wrong from the standpoint of the RFC, but from a intuitive > standpoint (that of everyone who does it) it makes perfect sense. > It's not at all difficult to interpret as it was intended by the > author. But how do you guess what the author intended? RFCs were (one of the reasons anyway) setup to not have to guess the infinite possibilities of the author's intentions. JA>> I think RitLabs have done the correct thing in following the RFCs JA>> correctly. The more compliance you have with standards, the more JA>> likely you are to do well. Start changing things, or flexing the rules JA>> slightly, and you end up having all kinds of problems. > Actually it tends to be the opposite. If you don't support > non-compliant stuff you start breaking clients/servers and data ends > up getting misrepresented/misdisplayed. And then that is the fault of the person/persons of the system at hand, not the authors of the package that is being misinterpreted. Yes I understand it is nice to flex the rules and try and make things compatible with everybody, but it is just not possible. There is probably an infinite number of possibilities on the way things 'can' be read, and 'should' be read. > If software writers, especially those who make web browsers didn't > support non-compliant stuff many pages wouldn't display quite right > or not at all (yes, even Opera does this). In fact, if you are so > strict as to accept only perfect compliance people probably would > stop using your browser because they would be limited to only those > websites who bothered to use the w3c validater (which is very few > sadly). I have started using it more recently, and found probably 75% of my code to be pretty accurate, but there were some mistakes ;) But I understand what you mean, if you forced compliancy with all aspects, you'd end up losing users, but then again, it doesn't help when it comes to producing valid code, and improve those that are coding incorrectly. > Besides, it IS just mailto, you really aren't hurting anything. I know this. I was just pointing out that, TB! is behaving just as the RFCs have said. It is taking the 'be lenient in what you accept..' as it is probably accepting all the input from your browser, it is just behaving as per what the RFCs say. Spaces get replaced with %20, it encounted a ' ', so the rest does not conform to the RFCs. This I don't feel is incorrect behavior, and wished more people would be more compliant. It'd save a lot of nightmares, and long nights in the office ;) But there is always somebody that likes to break them ;) Maybe this would be an ideal time to go TBOT? - -- Jonathan Angliss ([EMAIL PROTECTED]) -----BEGIN PGP SIGNATURE----- Comment: Fingerprint: 676A 1701 665B E343 E393 B8D2 2B83 E814 F8FD 1F73 iQA/AwUBPecf+SuD6BT4/R9zEQIlvgCaAzbBfowcJV5IyI/LthIgcdH+gRoAn3XU BFv06bOrJxopJdcu0qd4OKiJ =qCVe -----END PGP SIGNATURE----- ________________________________________________ Current version is 1.61 | "Using TBUDL" information: http://www.silverstones.com/thebat/TBUDLInfo.html
