[fetchmail]ODMR fixes

I was able to get ODMR working with www.mailkeep.com (with their
mail.mailkeep.com server).  As far as I can tell, this is the only
publicly available ODMR server on the entire Internet!  The site looks
shaky (help links lead to 404 errors, etc.), but the SMTP/ODMR stuff
seems to be working.

There are three bugs in the ODMR support.  Two are fairly trivial, one
requires some design before a good fix can be had (I just did a quick
hack).

All patches against 5.8.8.  I'd love it if they were committed!

First Bug:

    The ODMR code calls into the CRAM code.  Currently the CRAM code
    calls the base64 code without stripping protocol specific prefixes
    from the initial base64 challenge.  Since ODMR is CRAM-MD5 over
    SMTP, the challenge looks different -- it is a 334 SMTP response.
    This patch changes the base64 stuff to understand the SMTP
    response.  The right fix is to strip protocol stuff out before
    sending it to base64, but I am following a precident here:


--- base64.c.orig       Sat Mar  3 21:25:21 2001
+++ base64.c    Fri Jun 22 23:09:05 2001
@@ -60,6 +60,8 @@

     if (in[0] == '+' && in[1] == ' ')
        in += 2;
+    if (strncmp(in, "334 ", 4) == 0)
+       in += 4;
     if (*in == '\r')
        return(0);


Second Bug:

    odmr.c is missing a logout function, which was leading to seg
    faults.  I copied the one from ETRN.  (Included in patch below.)


Third Bug:

    There is contention for the smtphost param in the ODMR case.

    - On the one hand smtphost is the list of domains we'd like to
      have the ODMR server send us.  This is the "ETRN" meaning of
      smtphost, which now used by ODMR as well.

    - On the other hand, fetchmail needs a list of *local* SMTP
      servers to hook up with.  This is the "POP/IMAP" meaning of
      smtphost, and ODMR needs this list as well.

    I think he wrong move was probably overloading the meaning of
    smtphost for ETRN in the first place.  What we need is a
    "fetchdomain" parameter that is used in ETRN and ODMR, which
    leaves smtphost free for ODMR's use.

    Ideas?

    Anyway, the crash bug is in odmr_getrange()'s call to SockOpen().
    It simply uses ctl->smtphost, which in my case is NULL at the time
    of the call.  Because of the above ambiguities, I simply replaced
    it with the string "localhost".



--- odmr.c.orig Fri May 11 22:03:03 2001
+++ odmr.c      Sat Jun 23 00:52:24 2001
@@ -130,7 +130,14 @@
      * use select(2) to watch the read sides of both sockets and just
      * throw their data at each other.
      */
-    smtp_sock = SockOpen(ctl->smtphost, SMTP_PORT, NULL, NULL);
+    /*
+     * FIXME: we hardcode "localhost" here because ODMR is fighting
+     * over the ETRN meaning of smtphost and the POP/IMAP meaning.
+     * ODMR needs both meanings, but there is only one config var.  So
+     * for now ODMR always uses the "localhost" SMTP server to connect
+     * with locally.
+     */
+    smtp_sock = SockOpen("localhost", SMTP_PORT, NULL, NULL);
     if (smtp_sock == -1)
        return(PS_SOCKET);
     else
@@ -180,6 +187,12 @@
     return(0);
 }

+static int odmr_logout(int sock, struct query *ctl)
+/* send logout command */
+{
+    return(gen_transact(sock, "QUIT"));
+}
+
 const static struct method odmr =
 {
     "ODMR",            /* ODMR protocol */
@@ -201,7 +214,7 @@
     NULL,              /* no way to fetch body */
     NULL,              /* no message trailer */
     NULL,              /* how to delete a message */
-    NULL,              /* log out, we're done */
+    odmr_logout,       /* log out, we're done */
     FALSE,             /* no, we can't re-poll */
 };