Fidelity versus conformance
David A Golden <[email protected]> Thu, 19 Aug 2004 10:52:16 -0400
| Newsgroups | gmane.comp.lang.perl.modules.mail-box |
|---|---|
| Message-ID | <5.2.0.9.2.20040819101533.00b634a8@localhost> |
Maybe this is one digression too far from the header folding issues, but as I'm using Mail::Box for spam filtering and tagging, understanding Mail::Box's intended effects is important to me. I was looking through RFC2822 recently -- chasing down a problem my fiancee had on hotmail with an email address like "O'[email protected]" (turns out this is legal, but if not escaped properly, screws up hotmail's javascript which uses single-quotes...) I noticed that the 78 character recommendation is a SHOULD -- that's a lot stronger than an OPTIONAL. Now, usually, it's been my experience that Mail::Box takes broken messages (particularly headers) and tries to put them into some appropriate form. For example, Mail-Box will add a Message-ID header to a message that doesn't have one. This actually broke a test case of mine when I was using a minimal message (From, Date) as a test case and Mail::Box kept spitting it back with a Message-ID I wasn't expecting. (N.B. The RFC specifies that messages SHOULD have a message-id.) In the case of the 78 character line, Mark made the call to not implement the "SHOULD" -- for performance reasons and to keep the in-memory and in-file versions the same. In the case of the Message-ID, Mark follows the "SHOULD", despite a processing cost to generate the unique ID and the result that the in-memory version is different than the file input. In both cases, I think he probably made the right call -- certainly, Mail::Box needs Message-ID for its own use anyway.) However, this raises the broader question of whether Mail::Box should be trying to be as faithful as possible to the original message (from input or stored in a file) or whether Mail::Box should be trying to bring messages as far into complience with the RFC standards as possible. Or, perhaps, whether this should be a user-selectable configuration option or a user-callable function as different users may wish to trade off conformance and performance/fidelity. I.e.: Mail::Message->read($input, conform => 1); or $msg->conformToRFC(); A related question is whether Mail::Box should instead always try to output/save in conformance with the RFC (including all "SHOULD" recommendations), i.e. when printing a message or saving/editing a message in a mailbox, even if it doesn't conform the message at the time it reads it in? This would allow tools like SpamAssassin to retreive the message verbatim, but would ensure that any messages modified or generated by Mail::Box itself are output in the proper form. This is clearly a philosophical debate and probably varies by user depending on intended use, but I think it might be worth some consideration and likely documentation. Mark and others -- I'm curious to hear your views on the competing goals of "fidelity of original" versus "conformance to RFC". Personally, I lean a little more towards conformance. I'm willing to use a fairly heavy module like Mail::Box even with its performance costs (and memory footprint) because it's bulletproof or nearly so. I want something that I can throw the most horribly deformed messages at (from the poorest implemented or most intentionally malicious spam mailers) and get something back that makes sense of it within the standards. If I wanted/needed fidelity of source, I think I would just read the input raw and use some regexes for simple parsing (or else use the new Email::Simple module). Regards, and apologies for the long-windedness, David Golden