tpop3d-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tpop3d-discuss] Stealing C-Client locks incompatible with mailspool


From: Chris Lightfoot
Subject: Re: [tpop3d-discuss] Stealing C-Client locks incompatible with mailspool cache
Date: Fri, 22 Feb 2002 17:39:18 +0000
User-agent: Mutt/1.3.24i

On Fri, Feb 22, 2002 at 10:29:11AM -0700, Ben Schumacher wrote:
> While I realize that the metadata cache for is an experimental feature, I
> had it enabled on my system and noticed some issue when stealing C-Client
> locks. Specifically, after stealing a C-Client lock, it appears that the
> metadata cache contains invalid information and therefore truncates/splits
> messages.
> 
> My suspicion is that when releasing the C-Client lock, Pine alters
> messages in the spool and causes the metacache information to become
> misaligned with the mailspool file.
> 
> I haven't poked the code enough to figure out a fix, but I thought I'd let
> the world know so that it can, at least, be documented in the README.

OK. That's bad, since tpop3d should notice that the cache
is invalid under any circumstances. It does this by
comparing the MD5 hash of the start of the message -- the
same thing that's used for the UIDs, in fact.

(Hmm. There is, in fact, a problem with this-- one should
only add a message if the position of the start of the
following message is valid. The fix is fairly simple; I'll
put it into the next prerelease.)

> P.S. Chris- You said you had code that can parse the configuration line
> that you had come up with for TLS -- it was:
>   address[:port][(domain)][;tls=(auto|stls),certificate[,private-key]
> 
> Do you think you could forward that to me? I'd prefer not to rewrite code
> you've already written. In addition, what do you think would be the
> appropriate way to specify the user that tpop3d would setuid to while
> doing its TLS work? Should we alter the above configuration directive to:
>   address[:port][(domain)][;tls=(auto|stls),user,certificate[,private-key]

I think that the user under which TLS proxying runs can
probably be configured globally, unless there's a good
reason not to. If you do want to allow it to be chosen on
a per-listener basis, the above is fine.

-- 
 An Englishman thinks that 100 miles is a long way;
 an American thinks that 100 years is a long time.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]