Re: [Nmh-workers] message rewrite/fix up

2013-02-17 Thread David Levine
Here's what I currently have planned for mhfixmsg, comments?

-reformat currently only applies to text parts.  For future
expansion, it could require a content type.  Though other
types would need a subtype analogous to text/plain.

David


Usage: mhfixmsg [+folder] [msgs] [switches]
  switches are:
  -[no]decode
  -[no]textcodeset
  -[no]reformat
  -[no]fixboundary
  -[no]fixcte
  -file file
  -outfile file
  -[no]verbose
  -version
  -help


NAME
   mhfixmsg  -  rewrite MIME messages with various transforma-
   tions

SYNOPSIS
   mhfixmsg [+folder] [msgs] [-decode | -nodecode] [-textcode-
set codeset | -notextcodeset] [-reformat | -norefor-
mat] [-fixboundary | -nofixboundary] [-fixcte |
-nofixcte] [-file file] [-outfile outfile] [-verbose |
-noverbose] [-version] [-help]

DESCRIPTION
   mhfixmsg rewrites MIME messages, applying  specific  trans-
   formations  such  as decoding of MIME-encoded message parts
   and repairing invalid MIME headers.

   MIME messages are specified in RFC-2045 thru RFC-2049  (see
   mhbuild(1)).   The mhlist command is invaluable for viewing
   the content structure of MIME  messages.   mhfixmsg  passes
   non-MIME  messages through without any transformations.  If
   no transformations apply to a MIME  message,  the  original
   message or file is not modified or removed.

   The  -decode  switch enables a transformation to decode all
   base64 and quoted-printable message parts to  8-bit  encod-
   ing.

   The -textcodeset switch specifies that all text/plain parts
   of the message(s) should be converted to codeset.   Codeset
   conversions require that nmh be built with iconv(3).

   The  -reformat  switch  enables  a  transformation for text
   parts in the message.  For  each  text  part  that  is  not
   text/plain   and   that   does  not  have  a  corresponding
   text/plain in a multipart/alternative part, mhfixmsg  looks
   for   a  mhfixmsg-format-text/subtype  profile  entry  that
   matches the subtype of the part.  If one is found  and  can
   be  used  to  successfully  convert the part to text/plain,
   mhfixmsg inserts that text/plain part at the  beginning  of
   the containing multipart/alternative part.  It creates such
   a  multipart/alternative  part  if  one  was  not   already
   present.

   -reformat  requires a profile entry for each text part sub-
   type to be reformatted.   The  mhfixmsg-format-text/subtype
   profile  entries are based on external conversion programs,
   and are used the same way that mhshow uses its mhshow-show-
   text/subtype  entries.   When nmh is installed, it searches
   for a conversion program for text/html content, and if  one
   is  found,  inserts  a  mhfixmsg-format-text/html  entry in
   %etcdir%/mhn.defaults.  An entry of the same  name  in  the
   user's  profile takes precedence.  The user can add entries
   for other text subtypes to their profile.

   The -fixboundary switch enables a transformation to  repair
   the  boundary  portion  of the Content-Type header field of
   the message to match the boundaries of the outermost alter-
   native part of the message, if it does not.  That condition
   is indicated by a  "bogus  multipart  content  in  message"
   error message from mhlist and other nmh programs that parse
   MIME messages.

   The -fixcte switch enables a transformation to  change  the
   Content-Transfer-Encoding  from an invalid value to 8bit in
   message parts with a Content-Type of multipart, as required
   by RFC 2045, Section 6.4.  That condition is indicated by a
   "must be encoded in 7bit, 8bit, or  binary"  error  message
   from  mhlist  and  other  nmh programs that parse MIME mes-
   sages.

   If the -verbose switch is present, then mhfixmsg outputs an
   informational message for each transformation applied.

   The -file file switch directs mhfixmsg to use the specified
   file as the source message, rather than a  message  from  a
   folder.   If  this  file  is "-", then mhfixmsg accepts the
   source message on the standard input stream.  If  no  -out-
   file  switch  is  present  when  using  the  standard input
   stream, mhfixmsg will not produce a transformed output mes-
   sage.

   mhfixmsg,  by default, transforms the message in place.  If
   the -outfile switch is present, then mhfixmsg does not mod-
   ify  the input message or file, but instead places its out-
   put in the specified file.  An outfile name of  "-"  speci-
   fies the standard output stream.

   Combined  with the -verbose switch, the -outfile switch can
   be used to show what transformations mhfixmsg  would  apply
   without actually applying them, e.g.,

mhfix

Re: [Nmh-workers] message rewrite/fix up

2013-02-17 Thread Ralph Corderoy
Hi David,

>MIME messages are specified in RFC-2045 thru RFC-2049

`through'!  ;-)

Cheers, Ralph.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] message rewrite/fix up

2013-02-17 Thread Jerrad Pierce
Sounds great, where is it? :-P

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Pasing stdin to "inc -file" ?

2013-02-17 Thread Ronald F. Guilmette

In message <20130216223055.9b6af360...@charybdis.ellipsis.cx>, 
Joel Uckelman  wrote:

>Thus spake "Ronald F. Guilmette":
>> 
>> >For example, I've had this spam-filing recipe in my .procmailrc for ages:
>> >
>> >:0w: Mail/sp/$LOCKEXT
>> >* ^X-Bogosity: Spam, tests=bogofilter
>> >| /usr/libexec/nmh/rcvstore +sp
>> 
>> 
>> Can you help me to understand the first line of that?
>> 
>> Obviously, based on what I already posted, I _do_ understand the initial
>> ":0" part of that, and I just looked man the procmailrc man page and now
>> I have learned about the 'w" part.  But what's that other colon doing in
>> there?  And what is the significance of "Mail/sp/$LOCKEXT" ?
>
>The second colon tells procmail to use a lockfile for this recipe, and
>the path after that is the lockfile name. Messages can come in any
>time; the lockfile ensures that two runs of rcvstore don't step on each
>other's toes.
>
>The man page for procmailrc(5) is how I learned about this in the first
>place.


Thank you.  This has all been distinctly enlightening.


Regards,
rfg

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] message rewrite/fix up

2013-02-17 Thread Tethys

Ralph Corderoy writes:

>>MIME messages are specified in RFC-2045 thru RFC-2049
>
>`through'!  ;-)

If we're being picky about it, 'to'! :-)

Tet

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] message rewrite/fix up

2013-02-17 Thread David Levine
Tet wrote:

> Ralph Corderoy writes:
> 
> >>MIME messages are specified in RFC-2045 thru RFC-2049
> >
> >`through'!  ;-)
> 
> If we're being picky about it, 'to'! :-)

That was a copy and paste from one of the four other man
pages that has "thru".  I'll change them all to "to", though
my American English upbringing might suggest "through".

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers