Hello Stephen. Stephen Isard wrote in <[email protected]>: |>|If I telnet to the (successful) server, it responds with |>|Sendmail 8.14.7/8.14.7. The problem server says Sendmail 8.15.2. |> |> Thanks. Well ... to me this looks like a server error for now. |> In the meantime i have had a short glance at RFC 4954, and it |> seems to me 334 is not even continuable, not to talk about doing |> "334 " twice, it then really should be "334-" plus "334 ". | |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 and that is a totally different error than what we now seem to have to deal with, no? |> noone else ever |> encountered that? | |Does seem strange. Maybe the combination of s-nail, gssapi and 8.15.2 |isn't all that common. | |> Well tomorrow i could look into Alpine, if you say that this does |> NOT fail? Just wondering... | |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> you have shown last, which is different to the initial thing. Yes, GSS-API authentication requires round-tripping in a loop until GSS_S_CONTINUE_NEEDED is no longer seen. But if the above fails there should also be an error message then, in all thinkable cases, which this snippet misses. I mean, what do i know here?? You show the error in the first, but not in the second, and the second is different to the first. No??? I mean we do not support GSS-API enwrapping, for example, it could be that one server is configured to require that, for example. I would have claimed it obsolete two decades ago, OpenSSL was already present by then, but .. the world not. All _i_ know is that once i have rewritten all the GSS-API a bit different to what it was before and so that it can be shared in between IMAP, POP3 and SMTP, is that i have read all according documents and did testing with the test bed i finally created. And that, there, GSS-API just works out fine. With the restriction that you should not interrupt it, the MIT Kerberos at least does not take care for signals at all, and i do not suppress signals during this network task. (And getaddrinfo(3) seems to use static data, anyhow i can crash S-nail via getaddrinfo(3) from libc when doing GSS-API authentication multiple times, and i am fast enough or fake the condition to get there.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
