Who needs more than 73 parts in a message anyways? 99 is very arbitrary, less so than 255, which is a UCHAR.
you can also fit the number 99 in a uchar. (or byte in higher level languages). We somewhere have to set an upper limit and this should be a limit, that regular users understand, if they are looking at a spec. Specs are not only for developers, they are for users too who want to learn how stuff is built. Instead of putting up the number 255 (technically 256 because you cant have a multipart message with 0 parts) I use the number 99, because people understand the two digit limit better than the 2
n-1 logic. It technically does not matter at all because you will still be parsing ASCII text with your regular expression.
There are iFrames and other such things. Do you know the entire HTML spec? How about the entire MIME spec? The goal should be to prevent whole classes of attacks, not pick them off individually.
Are you from the past? When have you seen an E-mail client displaying iFrames? Even Internet Explorer 4 had protection against iFrame looping and this thing was a browser (or at least looked like one). This has nothing to do with MIME, this is a general application issue, if your client displays iFrame and probably also has a javascript engine.
I can't really get what you're saying. First, rewriting MIME parsers is going to be worse than making a new one from scratch. Have you seen the MIME RFC's?
Second, if you want it to be simpler than MIME, make it simpler than MIME.
Rewriting MIME parsers is easy, instead of checking for the mime border at the content-type tag you look at the first line. Much easier. E-mails have headers, bitmessage has none, a user beginning his message with the Text with the line
From: Me would already trigger header parsing. This thing does not only needs to be somewhat similar to MIME, it must also be compatible with the existing bitmessage standards. And the existing bitmessage standard has no real headers.
There are certainly reasons for values to be empty, as there is a difference between "I know the <attribute> and it's an empty string" and "I don't know the <attribute>."
Tell me the reason please? if the Subject header is missing, then there is no subject to display. If it is there but empty, there is no subject to display but the message is bigger for no reason, causing more POW.
NTFS specification allows paths to be 32,000 (2^15 or so) characters, so a USHORT (2^16) would make the most sense.
The Unicode versions of several functions permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters in length. To specify that kind of path, use the "\\?\" prefix. The maximum path of 32,000 characters is approximate, because the "\\?\" prefix can be expanded to a longer string, and the expansion applies to the total length.
And now you want to include NTFS paths in the headers? What the hell should a linux user do with your NTFS Path? If it is about File names being 255 chars long: this is not supported by all file systems, someone probably runs this from a FAT formatted USB drive, somebody has an old linux partition, where this is not supported. Filenames longer than 50 chars are suspicious and complicated to handle anyway, oh and on some linux filesystems you can have the colon ( : ) in file names, I want your NTFS see storing that. You seem concentrating too much on windows.
- Different from MIME, so no Python email lib
and no unneeded obsolete features, also there are other languages out there.
- As similar to MIME as possible, so no easy POSIX matching
This was the issue about dashes in the spec. I love that argument. just entered "regex" and "dash" into google and the first result was a regular expression from which you can easily derive the correct expression to parse it.
http://stackoverflow.com/questions/5887678/alphanumeric-dash-and-underscore-but-no-spaces-regular-expression-check-javascr- Different from MIME, so a new attachment type has to be implemented
It's not that much different from MIME if you have ever looked at a mime encoded mail
- As similar to MIME as possible, opening up security holes
So your failure in implementing a correct HTML rendering engine is now a MIME issue?
***ATTENTION! I start to be sarcastic below and you probably want to ignore it. Thanks***We probably should also include the autoexec attribute that can be true or false (or undefined). It defaults to "true", if it is true, the attachment is automatically stored on the harddrive and executed (in the reverse order they appear in the message just for fun).
***END***Just kidding, but seriously, this is not a MIME issue, this is a GUI issue because MIME just splits parts into pieces, nothing more. The only thing you need to do is prevent inclusion by building a tree with references. If a reference appears multiple times on different levels (1.html --> 2.html --> 3.html --> 1.html) you got a recursion. Browsers are doing the same thing.