3 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: more openwall...
FromSent OnAttachments
John WatsonNov 29, 2000 9:55 am 
Sam VarshavchikNov 29, 2000 2:59 pm 
John WatsonNov 29, 2000 4:08 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] Re: more openwall questions for SamActions...
From:John Watson (jo@wirex.com)
Date:Nov 29, 2000 4:08:49 pm
List:net.sourceforge.lists.courier-users

Thanks for the prompt and detailed response. With this information, we've decided to leave courier alone, and continue with our orginial plan of patching the openwall patch. Thanks again! John

On Wed, Nov 29, 2000 at 10:59:05PM +0000, Sam Varshavchik wrote:

John Watson writes:

Hi Sam. We're trying to reconcile courier with the openwall patch (again). We're trying to figure out how to patch courier so that it doesn't conflict with the "no hard links to files other people own" rule. This has led us to the tmpscan() function called in courierdb.C. We're trying to figure out what the motivation is for putting hardlinks to all the files in a single directory. We've been staring at the code for a while, and can't really figure it out. Would you mind giving us some insight into why things are built this way, so we can figure out how to approach the problem?

Courier mail queue is implemented in part based on filesystem semantics. It is not something that can be described in just a few sentences. You will find some additional information in the following documents:

http://www.courier-mta.org/layout.html

http://www.courier-mta.org/queue.html

To summarize: hard links are used to presort messages in the mail queue according to their next scheduled delivery time. There's a separate directory that's automatically created for each time slot that lasts approximately three and a half hours. A message is scheduled for delivery by creating a hard link to that message in the directory that corresponds to its next scheduled delivery time. Therefore, when the mail queue gets large it is not necessary to read all of it in order to figure out which messages must be delivered first, it is only necessary to read the directory corresponding to the earliest time slot in order to pick up the messages that must be delivered first.

It is true that the current default retry intervals set a maximum retry interval of two hours, so there won't be more than two schedule directories in existence at a time. However, the retry intervals are adjustable; also when the mail queue backs up messages may wait longer for their next delivery attempt, so their delivery intervals will begin to stagger, so at this time this automatic splitting up of the mail queue by next scheduled delivery time is going to keep things from getting clogged up even further.

Basically, hard linking is a core part of mail queue processing, and cannot be avoided. When mail is submitted to the queue, the queue files for the messages are owned by the userid that submitted the message, and the group id is reset to the Courier group id. Keeping the original userid is needed for audit tracking, for the ability of the original sender to cancel the message, and the original sender's ability to obtain the mail queue status only for his/her own messages; the sender cannot access other senders' mail data (except for root, who can see all).