Re: LocalDelivery and Delivered-To
Is the addition of a Delivered-To header called for in an RFC? If so, where? I'm having trouble finding it. From the a comment in the source of the LocalDelivery mailet, I surmise that this practice originated with Qmail. Is that correct? By the way, I want to thank the James team for assembling the folder of relevant RFCs and including them with the distribution. I've got a link to that on my desktop. Very useful. Rich Hammer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LocalDelivery and Delivered-To
Unfortunately, not true, The LocalDelivery mailet is called to delivery
to
all local recipients associated with a message. Each one needs a unique
Delivered-To header, which is additive with any Deliverted-To headers that
might already exist.
Yes, no doubt about that.
The code for doing that does need to be written, but the requirements
still
need to be kept in mind.
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 that
...
message.addHeader(Delivered-To, recipient.toString());
// no message.saveChanges();
...
and it's working fine for me. I do have the Delivered-To-Header in all of
my
local-mails (didn't removed the for-loop).
My point is that you dont have to call saveChanges() in order to add a
Header
as long as the body didn't change or at least doesn't contain any non ascii
characters.
My James version im working with is quite different but I dont think it has
any affect
on this peace of code. For example I dont duplicate the mail in the
LinearProcessor
when it gets to the next mailet just use a reference. Therefor I also have
to remove the
Header on exit of LocalDelivery.
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.
M
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: LocalDelivery and Delivered-To
- Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 5:17 PM Subject: RE: LocalDelivery and Delivered-To 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. Yes, I have taken that into account and thats also why I have to remove the header after leaving LocalDelivery 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. Different approach same result. But my message isnt loaded into memory. 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. Yes, the situation when theres a mix of recipients. This duplication was eliminated. Not a big change but quicker. I've been aware of this issue, and am planning address it shortly. One thing that you can do is use the dbfile protocol. I added an additional tag in my config-file setting the max messagesize of mails I dont want to store in the DB. If the size is exceeded I move the tmp-file (.m64) into the users inbox and reset the filelocation in the messagesource object, so finally the mail wont be loaded into memory ever. 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? If it can be usefull I will, but I am afraid I made too many changes that only meet my needs. The first thing I did with version 2.1 was removing pheonix. My start up of James is done in a single class. I was alienated by the fact that an email server is integrated into a container because in my opinion this is a classic stand alone app but this is only a question of taste, so we shouldnt argue about that. Already at this point I doubted that I could make any useful contributions besides expressing general ideas or addressing very specific issues. Another point was the spooler. I have two (different versions) of them. One for my incoming messages and another for my error-messages. Loading the same mail repeatedly into one spooler wasnt as efficient as I thought it should be. A message cache for/in the MailRepositories also improved the performance. Also a cache for the PreparedStatements. The only thing left is clustering capabilities which is the next I will be on as far as I can free time for it. This reminds me of a debate earlier this year. If I am really concerned about failure detection and prevention I would definetly use a cluster and dont invest my energy in creating interprocess software communication on a single machine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: LocalDelivery and Delivered-To
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. Yes, I have taken that into account and thats also why I have to remove the header after leaving LocalDelivery You would have to remove it within the loop, since that loop is delivering to all of the local recipients associated with the message. 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. Different approach same result. But my message isnt loaded into memory. There is no question that the MimeMessage handling needs to be done differently in that code and a couple of others. I've said that since it was done, but haven't had the time to fix it. That is something I intend to do shortly. 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. Yes, the situation when theres a mix of recipients. This duplication was eliminated. Not a big change but quicker. So what are you doing to track the multiple recipient sets, whose lifetime is not processor scoped? I added an additional tag in my config-file setting the max messagesize of mails I dont want to store in the DB. So you automatically shift between db and file store based upon the message size? Interesting idea. 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? A message cache for/in the MailRepositories also improved the performance. Also a cache for the PreparedStatements. The latter should be handled by DBCP. The former is something we could do, but has other implications. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LocalDelivery and Delivered-To
Yes, I have taken that into account and thats also why I have to remove the header after leaving LocalDelivery You would have to remove it within the loop, since that loop is delivering to all of the local recipients associated with the message. Thats correct. Therefor I use an additional header-list in MimeMessageWrapper which is also written to the OutputStream in the writeTo-methods. Yes, the situation when theres a mix of recipients. This duplication was eliminated. Not a big change but quicker. So what are you doing to track the multiple recipient sets, whose lifetime is not processor scoped? Default behavior of the matcher and recipient sets is recipientconsumption. That means if there are recipients the matcher doesnt catch this recipients are the new ones for the mail in the next mailet. If I add a tag in a mailet (in the config-file) like consumeRecipientsfalse/consumeRecipients the recipients of the next matcher-mailet pair is the same as the actuall one. I also find it helpful to introduce some kind of composition behavior like having a list in the MailImpl-object that contains all the mailetnames that should ignore this mail. So each Mailet asks this list if its name is in it and if so the Mailet does nothing. But this is only for my special needs as I have up to 4 rounds of the same mail in the pipeline; a case where state-handling gets a bit tricky. I added an additional tag in my config-file setting the max messagesize of mails I dont want to store in the DB. So you automatically shift between db and file store based upon the message size? Interesting idea. Yes thats true, since Ive given up plans storing large mails in the db because of the db specific code thats needed for this task. A message cache for/in the MailRepositories also improved the performance. Also a cache for the PreparedStatements. The latter should be handled by DBCP. The former is something we could do, but has other implications. Another cache I use is a inboxrepository cache for the pop3handler. You have mentioned earlier that the inboxrepositories are created for each user and are hold in a collection. You have declared this as a bug. (A quick and dirty fix would be a WeakHashMap) By the way I remember that I had a bad feeling regarding the errorhandling in LinearProcessor. I am not sure if the sender of a mail gets an error message if the db fails. M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
LocalDelivery and Delivered-To
Adding the Delivered-To-Header by creating a new MimeMessage is unnecessary work. A simple message.addHeader(Delivered-To,recipient.toString()); would be enough (without calling updateHeaders()). M
RE: LocalDelivery and Delivered-To
Adding the Delivered-To-Header by creating a new MimeMessage is unnecessary work. A simple message.addHeader(Delivered-To,recipient.toString()); would be enough (without calling updateHeaders()). Unfortunately, not true, The LocalDelivery mailet is called to delivery to all local recipients associated with a message. Each one needs a unique Delivered-To header, which is additive with any Deliverted-To headers that might already exist. The code for doing that does need to be written, but the requirements still need to be kept in mind. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
