> To make things clear I replaced this
> // Add qmail's de facto standard Delivered-To header
> MimeMessage localMessage = new MimeMessage(message) {
> protected void updateHeaders() throws MessagingException {
> if (getMessageID() == null) super.updateHeaders();
> else {
> modified = false;
> }
> }
> };
> localMessage.addHeader("Delivered-To", recipient.toString());
> localMessage.saveChanges();
> with
> message.addHeader("Delivered-To", recipient.toString());
> and it's working fine for me.
Send an e-mail to multiple local recipients. Each time you call addHeader,
you should be adding a new Delivered-To header to the message, which means
that you will be accumulating additional headers. If you only have one
local recipient, you'll never notice the difference.
The call to saveChanges is required by the JavaMail specification, but we
end up short-circuiting it, which is the whole purpose for our
updateHeaders() method.
> My James version im working with is quite different but
> I dont think it has any affect on this peace of code.
Do you want to submit any of your changes for consideration?
> I dont duplicate the mail in the LinearProcessor when it
> gets to the next mailet just use a reference. Therefore
> I also have to remove the Header on exit of LocalDelivery.
The only place we create a duplicate in LinearProcessor is where we have two
paths for a Mail to take after a matcher. IFF there are recipients for both
paths, a duplicate is made of the Mail, which is just the processing
envelope not the message contents, to track the dual paths.
> My intention was bringing the tmp-file from the smpt-handler
> (.m64) to my LocalDelivery-mailet without any additional
> processing (inserts in DB or copies in filesystem(only move))
> and without loading the mail into memory in case its a really
> big one. One place where the message is loaded into memory is
> the new instance of MimeMessage above.
I've been aware of this issue, and am planning address it shortly. One
thing that you can do is use the dbfile protocol. It turns out to be the
most efficient at the moment, especially with large messages.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
