With my laptop's hard drive dead, and my only access at home a PC with no
graphics, last night I was trying to use lynx with sqwebmail (3.6.0) to send
some messages. I was using lynx -resubmit_posts as discussed on the list
before.

However, this has lead to some confusing and slightly embarrasing results!
Some of which appears to be down to sqwebmail, see later.

I successfully sent one message, but every line break was converted to the
text string "da", and paragraph breaks to "dada". You can imagine how it
sounded; my friend mailed it back to me to say how much he'd laughed!

The subsequent messages I tried to send, though, were silently ignored.
sqwebmail went back to the Folder listing, but the message did not appear in
the Sent folder, nor was any message submitted to the MTA (according to its
logs), and nothing was output to stderr (according to Apache logs)

Now, I have been debugging this with tcpdump this morning. The problems
appear to be:

(1) lynx is posting messages with "msgtoken=&" (i.e. empty) instead of
    "msgtoken=nnnnnnn-nnnn&"

This is very odd, almost certainly a lynx bug, because it's in the source
HTML:

0x0450   653d 2222 202f 3e3c 696e 7075 7420 7479        e=""./><input.ty
0x0460   7065 3d22 6869 6464 656e 2220 6e61 6d65        pe="hidden".name
0x0470   3d22 666f 6375 7374 6f22 2076 616c 7565        ="focusto".value
0x0480   3d22 6865 6164 6572 7322 202f 3e3c 696e        ="headers"./><in
0x0490   7075 7420 7479 7065 3d22 6869 6464 656e        put.type="hidden
0x04a0   2220 6e61 6d65 3d22 6d73 6774 6f6b 656e        ".name="msgtoken
0x04b0   2220 7661 6c75 653d 2231 3036 3237 3536        ".value="1062756
0x04c0   3035 312d 3335 3333 3122 202f 3e3c 7461        051-35331"./><ta

But what it means is that sqwebmail thinks that every message being
submitted has the same message token (stored in file "sqwebmail-token" in
the maildir) and is therefore a duplicate, and is discarded. So the first
mail you send with lynx is sent, the others are duplicates.

I've upgraded to the most recent dev version (2.8.5dev.16) and the problem
still seems to be there.

So I have done a minor patch to work around the lynx problem: it might be
worth incorporating even though it's lynx which is broken, not sqwebmail.

--- sqwebmail-3.6.0/sqwebmail/token.c.orig      Fri Sep  5 12:02:59 2003
+++ sqwebmail-3.6.0/sqwebmail/token.c   Fri Sep  5 12:03:40 2003
@@ -50,6 +50,8 @@
 const char *token=cgi("msgtoken");
 const char *savedtoken;
 
+       if (!token || token[0] == '\0')
+               return(0);
        savedtoken=read_sqconfig(".", TOKENFILE, 0);
        if (savedtoken && strcmp(token, savedtoken) == 0)
                return (-1);


(2) Now, as for the "dada" problem, it turns out that lynx was posting %0d0a
whereas konqueror posts %0D%0A, and sqwebmail only honours capital letters.
So the fix is:

--- sqwebmail-3.6.0/cgi/cgi.c.orig      Fri Sep  5 12:17:54 2003
+++ sqwebmail-3.6.0/cgi/cgi.c   Fri Sep  5 12:18:33 2003
@@ -329,6 +329,8 @@
                (*n) = (*n) * 16 + (*p++ - '0');
        else if ( *p >= 'A' && *p <= 'F')
                (*n) = (*n) * 16 + (*p++ - 'A' + 10);
+       else if ( *p >= 'a' && *p <= 'f')
+               (*n) = (*n) * 16 + (*p++ - 'a' + 10);
        return (p);
 }
 
I'd say this is definitely a sqwebmail bug, since RFC1738 explicitly allows
lower-case letters in hex encodings:

   In addition, octets may be encoded by a character triplet consisting
   of the character "%" followed by the two hexadecimal digits (from
   "0123456789ABCDEF") which forming the hexadecimal value of the octet.
   (The characters "abcdef" may also be used in hexadecimal encodings.)

as does RFC2396:

2.4.1. Escaped Encoding

   An escaped octet is encoded as a character triplet, consisting of the
   percent character "%" followed by the two hexadecimal digits
   representing the octet code. For example, "%20" is the escaped
   encoding for the US-ASCII space character.

      escaped     = "%" hex hex
      hex         = digit | "A" | "B" | "C" | "D" | "E" | "F" |
                            "a" | "b" | "c" | "d" | "e" | "f"

With those two patches, everything seems to be working again. I will have a
dig round the lynx source code to try and find out what's going wrong with
the msgtoken hidden field.

Regards,

Brian.

Reply via email to