[pskmail] Re: Server 1.4.0a email access issue

  • From: "Rein Couperus" <rein@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Wed, 24 Aug 2011 16:04:22 +0200 (CEST)

Have  you entered a link password via the prefs dialogue?

It works like this:
* You set a link password on the client (Prefs dialogue)
* You send it to the server with :SETPASSWORD
* The server says 'Your link password has changed'.

If you connect the next time, the server will send a challenge as part of the 
'version' message.
When the client receives the challenge from the server, it also generates a 
The client generates a cookie on the basis of the link password and both 
The client sends its challenge and the cookie to the server.
The server checks if the cookie is valid and says 'OK...'.

If the client uses a different password authorization fails...

That way somebody using your call cannot get your mail.

Rein PA0R


HI Rein,
I have re-sent the mail record and everything seems to be working now.
But I don't understand the usage and objective of the :SETPASSWORD thingy 
below. Looking at the client code it seems to create a key but I haven't seen 
that being exchanged between the client and server and still I can access my 
So I am at a loss as to how that works, and I read the documentation this time 

On Tue, Aug 23, 2011 at 1:05 AM, Rein Couperus 
<rein@xxxxxxxxxxxx[mailto:rein@xxxxxxxxxxxx]> wrote:
You bet something changed...

In client 1.34 and server 1.4.0a the mail record has changed.
Passwords are now encrypted in the server database.
All this is described in the new client manual.

The procedure is simple:
* resend mail record to server, that will store the pop password
* send your link password to the server (:SETPASSWORD).
After that all will be normal (unless there are other problems).


Rein PA0R



When I upgraded from 1.0.28 to 1.4.0a I can´t access my ISP´s email account 
despite using the same 
config file.

My account is accessed with plain password since it is cable internet.

The server keeps replying with No Mail to the client and the mail count at 
connect time shows -1 in the server log.

Has anything changed in that area?

Also, when I tested the three options for resuming or not an uncompleted 
download, I noticed that when I selected Reject, the server deleted the 
transaction as for Discard. Is this the expected behaviour or should it not 
send it in the current session but leave the partial download for next time?



Other related posts: