Jukka Zitting ha scritto: >> The MOST IMPORTANT thing at all is that if I store a message and I later >> retrieve it every single space, every single header, everything is >> exactly as I wrote it. Even if it was malformed. > > Is this a hard requirement? If yes, then I could just model the entire > mime message as a normal nt:resource node, in which case the JCR > repository would act just like an advanced file system with > transactions and some search features.
As JAMES Server can be used as a relay server, the SMTP specification tell us to not alter the messages (even if they are malformed). The only thing we're allowed to to is *prepending* a "Received" header, and converting from 8bit to 7bit if we support 8BITMIME. I think SMTP relaying is a common use case for JAMES Server and one of the main goals so we should keep this in high consideration. > Personally I don't see the exact storage requirement as essential, as > the mail specs explicitly allow all sorts of intermediate nodes to > perform various types of reformattings on messages while in transit. > Things should be fine as long as the original intended content is > preserved. Are you sure? I don't agree on this. Instead you break some signature mechanism if you do that. My interpretation of the SMTP spec is not that we can do what we want. Maybe other JAMES committers can share their experience and knowledge on this. >> To achieve performance we'll probably have to avoid parsing the mime >> structure at all: we don't need this for most SMTP/POP3 operations. Some >> IMAP operation needs this, but this should probably done on demand and >> not when writing the message to the repository. > > One possible approach, at the expense of storing potentially redundant > duplicate data, is that the original message source is stored as a > verbatim binary stream and the message content is automatically > "exploded" when the first client that actually needs to parse the > message. This is what we do now (MimeMessageWrapper does lazy parsing of headers/body separately), but we never store the "parsed" version then. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
