Well, except for the mess that is RFC 822. At least NNTP decided to go 8-bit safe eons ago, so you just have to shove everything in UTF-8 and you can screw RFC 2047 in the face.
* RFC 2047 is a pain in the butt
* Handling attachments can be difficult (particularly the inability to safely add binary data)
* The display name/address is both painful in terms of syntax.
* CFWS in general (you can tell who's written an email client by their reaction to the letters CFWS)
* Header fields in general have way too lenient handling, so there's no way to, e.g., guarantee non-ASCII handling (RFC 2047 needs to be handled differently in the Subject: header than from the From: header, and the Content-Type: header does something else entirely).
* Mandatory line-length limits, which means you need to be able to insert line breaks in however you encode custom header values
* No way to get attachments without the body or vice versa
* All metadata needs to be shoved into a header (see above about i18n, line length, and CFWS)
What would you add? Remove?
Why?
For myself: the basic RF282 concept of sender, subject, recipient (or newsgroup), date, and references, plus body, seem reasonable.
How best to take these to present capabilities (and needs) is another question.
I think Gmane 2.0, if it ever will be born, would have a mechanism of plugins, that allow easy wrapping any web-forum in it, by writing a little template describing the layout of pages like 'this is topic, this is message body' and so on. And the crawler to use the plugins, of course.
[1] http://perldoc.perl.org/perltie.html