-#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 */