DLSauers posted on Thu, 10 Nov 2016 02:16:58 +0000 as excerpted: > I am looking to have a definitive PER *_RFC_* answer that a client > regardless of SERVER should issue MODE READER, get 500, done, click! Or > do what one client does, ignore the 500 issue LIST and go on....
I'll punt for the moment on what you're asking for, but never-the-less, here's my immediate thoughts. A practical and common RFC guideline and general policy is: Interpret the RFCs strictly in what you send, but be more tolerant in what you are prepared to receive. In this case, that would mean that regardless of whether the RFCs mandate MODE READER or not, particularly given that there are known servers out there that don't support it, pan should be prepared to work around receiving an error for the command, and continue without it the best it can. I /was/ going to suggest that a workaround would be using a firewall to block the 500 error response and replace it with a synthetic response that looks more like what pan expects. However, I expect once pan got that, it would continue making requests as if it were in reader mode, so it's not as simple as that, as a whole bunch of translation and synthetic response generation would need to be done. Which means the only real solution if you're going to use pan with that server is finding someone who knows enough C++ and is either familiar enough with the RFCs or willing to /become/ familiar enough with them to create and submit a patch... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
