I am trying to use imapd and/or pop3d they both give me the same issue.
When I try to connect to the server, it gives me this error:
ld.so.1: ipop3d: fatal: libssl.so.0.9.6: open failed: No such file or
directory
Connection closed by foreign host.
However the libssl.so.0.9.6 file exists, so I a
When I compile imapd with PAM support, it appears to work properly with
the PAM modules in use.
I compiled ipop3d at the same time, but it doesn't seem to be using PAM at
all in the authentication process. Any ideas?
from my /etc/pam.conf (pam_listfile_imap.so is a hacked pam_listfile
pointing t
The only actions that can take place before the initial banner that may
consume time are:
1) DNS lookup of the local host name.
2) ident lookup by [x]inetd
I suspect an ident lookup. Check your TCP wrappers configuration.
On Mon, 23 Dec 2002 16:46:37 +0530, venkat Devarajan wrote:
> Why dont the fetch and store commands not warrant unsolicited EXPUNGE
> replies ?
You can pipeline FETCH or STORE commands; that is, you can send multiple
commands at a time.
If untagged EXPUNGE responses were allowed, then the sequenc
Mark Crispin wrote:
I don't think that subsequent changes to the flags in either the original or
the copy should in any way effect the other. The specification doesn't forbid
such behavior, but it is not the role of the specification to forbid silly
behavior.
Thanks. It's the silly behaviour
Hi, I've recently installed imap-uw imapd. I worked perfectly for a few
days but recently clients seem to time out when connecting.
Telnetting from anywhere (including localhost) I see the following
behaviour:
mike@shadow:~$telnet localhost imap
Trying 127.0.0.1...
Connected to localhost.
Escap
Hi,
Why dont the fetch and store commands not warrant unsolicited EXPUNGE
replies ?
To elaborate:-
* 2 imap clients access the same mailbox and one does a fetch while
other does a set delete flag and expunge on the same message.
When the first client (which did a fetch) executes another fetch or
s
The specification is quite explicit: flags SHOULD be copied from the original
message to the copy at the time the copy is made.
I don't think that subsequent changes to the flags in either the original or
the copy should in any way effect the other. The specification doesn't forbid
such behavior,