home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / mail / pmdf / 2225 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  3.2 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!news.nd.edu!bsu-cs!news.cs.indiana.edu!syscon!gator!inland!cmkrnl!infopiz!mccall!ipmdf-newsgate!list
  2. From: ned@innosoft.com (Ned Freed)
  3. Newsgroups: vmsnet.mail.pmdf
  4. Subject: RE: Erroneous output from CONFIGURE.COM
  5. Message-ID: <01GOD2DV8C029FM7LA@INNOSOFT.COM>
  6. Date: 3 Sep 92 14:37:48 GMT
  7. Organization: The Internet
  8. Lines: 51
  9. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  10. Resent-Date: 03 Sep 1992 21:37:48 -0700 (PDT)
  11. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  12. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  13. Resent-Message-ID: <01GOD2ETB4EQ95NKT2@YMIR.CLAREMONT.EDU>
  14. X-Vms-To: IN%"JEREMY@vsm.com.au"
  15. X-Vms-Cc: IPMDF
  16. Mime-Version: 1.0
  17. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  18. Content-Transfer-Encoding: 7BIT
  19.  
  20. > That makes sense, I told it the official local host name was r.s.g.a, not
  21. > SERF.r.s.g.a which was the default response.  Although this does mean I
  22. > have mis-understodd how the rewrite rules and the channel blocks interact.
  23.  
  24. I have changed CONFIGURE.COM so that in the future it will insure that the
  25. official local host name gets its own rewrite rules.
  26.  
  27. > Actually, no.  I just did this:
  28. > $ MAIL
  29. > MAIL> send
  30. > To:   in%"sysprgg@paper"
  31. > Subj: Test mail to paper
  32. > Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
  33. > This is a short test message to paper.
  34. > ^Z
  35. > MAIL>
  36.  
  37. > Didn't work.  I removed the "charset7 us-ascii" without success, and then
  38. > also the "charset8 iso-8859-1" and that didn't help either.
  39.  
  40. Did you remove them from both the D AND the L channels? You have to get rid of
  41. it in both places. charset8 has nothing to do with it unless you use 8-bit
  42. characters. You can also solve the problem by getting rid of the linelength
  43. limits. The proper solution, of course, is to get a newer version of PMDF that
  44. handles this interaction correctly. Please contact your distributor if you want
  45. a updated version; all distributors have had updated versions in hand for quite
  46. a while.
  47.  
  48. Dan was incorrect on one point -- the problem has nothing to do with actually
  49. having long lines. The problem is rather due to the fact that a line length
  50. limit was given AND a character set was given WITHOUT providing an incentive
  51. for an actual detailed length check of the message. The result is that the
  52. general MIME converter in PMDF doesn't know the lengths but knows there's a
  53. limit; it then assumes the worst and encodes "just to be on the safe side".
  54. This is also the reason base64 is used -- there is no frequency information
  55. available to indicate that quoted-printable would be a better choice.
  56.  
  57. This problem was corrected by making a bunch of different and interrelated
  58. changes. In some cases more analysis is now done and in others the converter is
  59. no longer quite so strict.
  60.  
  61. All this is an unfortunate consequence of the interaction of linelengths and
  62. character sets. I have described the problem and the ways to solve it in
  63. previous info-pmdf postings. I am fairly sure this is the problem you're
  64. seeing; the symptoms are absolutely identical to previous problem reports.
  65.  
  66. If you cannot get things to work even after you have removed all linelength and
  67. charset7 specifications and recompiled and reinstalled (if you use a compiled
  68. configuration) please send me your configuration and I'll look into it further.
  69.  
  70.                 Ned
  71.