🚀 go-pugleaf

>>>>> "Kevin" == Kevin Rodgers <ihs_4664@yahoo.com> writes:

    Kevin> I think it's more likely that the last long paragraph
    Kevin> didn't contain any newlines, and combined with your
    Kevin> signature formed one line longer than the 998-character
    Kevin> limit.  Can you verify that?

Something in the encoding/decoding process appears to have produced
just that result.  But see below.

    Kevin> I'm guessing that a newline between the last line of
    Kevin> message text and the signature would prevent the two from
    Kevin> being counted as one long line -- unless your signature is
    Kevin> larger than 998 characters by itself.  Then VM needs to be

In the composition buffer, I always had a newline between the final
line of the message and my signature (which was never longer than four
lines, plus a linefeed).  When the base64-encoded message was decoded,
however, all newlines were stripped from the email, with the effect
that you describe above.  Oddly, though, this happened when the
message was decoded on one host (IRIX), but not others (Solaris and
Linux).  The IRIX server's sendmail (that's /usr/lib/sendmail, not
Emacs' sendmail) auto-converts text/plain MIME email.  The Sun and
Linux boxes retained (or reinserted) the linefeeds in the
base64-encoded messages.  In the latter two cases the messages were
decoded in VM by the mimencode and base64-decode external programs.

    Kevin> told to ignore the intangible property.  That's probably a
    Kevin> good idea anyway, so here's a patch to
    Kevin> vm-determine-proper-content-transfer-encoding; does it
    Kevin> help?

I'll apply the patch, re-enable vmpc-intangible-sig, and let you know
what happens.

VM is the best-supported software package I've ever encountered.
Thanks for your help.

-- 
Jorge Gonz�lez
jorge@aeth.org