|But the continuation doesn't cause a problem for s-nail. That's the
|server which succeeds. It's apparently something else that causes
|failures with 8.15.2.
Well i yet have not yet seen a single log that makes sense or
describes what you say. The only full log i have seen was
s-nail: >>> AUTH GSSAPI
...
s-nail: >>> SERVER: 334
...
s-nail: GSSAPI error: gss_init_sec_context / An invalid name was
supplied
s-nail: GSSAPI error: gss_init_sec_context / Success
That is what I get from the problem server with verbose=2 set. I have
never seen a success from that server with verbose=2 set, so I can't
show you a log of it succeeding. I do sometimes succeed _without_
verbose=2, but then there is no log. That was why I referred to the
uncertainty principle - trying to observe the phenomenon appears
to change it.
and that is a totally different error than what we now seem to
have to deal with, no?
No. You say that having two SERVER: 334 lines violates rfcs, but I only
see them in cases where the message goes through. So even if they
are a technical violation, they don't appear to be a problem for s-nail.
|Correct. Alpine does not fail. I have just tried it in debug mode with
|the 8.15.2 server and I see the same thing as with s-nail on the
|(successful) 8.14.7 server:
|
|IMAP DEBUG 19:31:15 8/17: 334 <lots of characters>
|IMAP DEBUG 19:31:15 8/17:
|IMAP DEBUG 19:31:15 8/17: 334 <some more characters>
Just like that
s-nail: >>> SERVER: 334 <lots of characters>
s-nail: >>>
s-nail: >>> SERVER: 334 <some more characters>
Yes. the Alpine log for the problem server is the same as the s-nail log
for the good server.
you have shown last, which is different to the initial thing.
Sorry, I don't know what you mean here. Which initial thing?
You show the error in the first, but not in the
second, and the second is different to the first. No???
Again, I am getting lost. I started this thread saying that I could
sometimes, but not always, send through the problem server. You made
the sensible request that I send you a log from a success and a log
from a failure so that you could try to figure out what was going wrong.
I tried to do that, but I couldn't, because there is never a success
with that server when logging is turned on.
I did manage a success from a different server with logging turned on
and showed you the log, but you don't like it because it has two 334
lines. Nevertheless, it is what got printed during a successful send
from s-nail.
I can't think of anything else to say about the problem, so I suggest we
drop it unless/until one of us has a new idea. I am sure other list
subscribers will be glad.
Stephen Isard
