+
+#ifdef FORCE_STUFFING /* too ugly to live -- besides, there's IMAP */
+ /* OK, very weird hack coming up here:
+ * When POP3 servers send us a message, they're supposed to
+ * terminate the message with a line containing only a dot. To protect
+ * against lines in the real message that might contain only a dot,
+ * they're supposed to preface any line that starts with a dot with
+ * an additional dot, which will be removed on the client side. That
+ * process, called byte-stuffing (and unstuffing) is really not the
+ * concern of this low-level routine, ordinarily, but there are some
+ * POP servers (and maybe IMAP servers too, who knows) that fail to
+ * do the byte-stuffing, and this routine is the best place to try to
+ * identify and fix that fault.
+ *
+ * Since the DOT line is supposed to come only at the end of a
+ * message, the implication is that right after we see it, the server
+ * is supposed to go back to waiting for the next command. There
+ * isn't supposed to be any more data to read after we see the dot.
+ * THEREFORE, if we see more data to be read after something that
+ * looks like the dot line, then probably the server is failing to
+ * do byte-stuffing. In that case, we'll byte-pack it for them so
+ * that the higher-level routines see things as hunky-dorey.
+ * This is not a perfect test or fix by any means (it has an
+ * obvious race condition, for one thing), but it should at least
+ * reduce the nastiness that ensues when people don't know how
+ * to write POP servers.
+ */
+ if ((maxavailable > (bp-buf)) &&
+ ((((bp-buf) == 3) &&
+ (buf[0] == '.') &&
+ (buf[1] == '\r') &&
+ (buf[2] == '\n')) ||
+ (((bp-buf) == 2) &&
+ (buf[0] == '.') &&
+ (buf[1] == '\n')))) {
+
+ memmove(buf+1, buf, (bp-buf)+1);
+ buf[0] = '.';
+ bp++;
+ }
+#endif /* FORCE_STUFFING */