headers
Paul Fox | 17 Apr 2005 16:06
Picon
Favicon

flattening continuation lines

i have what feels like a simple problem.

i want to post-process the output of mhbuild to add a "Content-disposition"
header after any Content-type header that matches some criteria.

i have this pretty much working, with the following:

    #!/bin/sh

    # add a Content-disposition field for every Content-Type that ends
    # in "name=<filename>".  Content-disposition is always attachment,
    # and filename is duplicated.

    draft=$1
    cat $1 |
	mhbuild - |
	sed 's/^Content-Type:.* name=\([^;= ]*\)$/&\
    Content-disposition: attachment; filename=\1/' >$1.new && \
	mv $1.new $1

but this will of course break if the Content-type header spans
multiple lines, if the first of those lines happens to match my
pattern.  so i'd like to flatten continuation lines before running
sed.  i've found jerry peek's little sed script to flatten such
lines:

    function join_header_continuations()
    {
       sed -n -e '
	/^$/,$p
(Continue reading)

Permalink | Reply | 5 comments |
headers
Oliver Kiddle | 18 Apr 2005 12:34
Picon
Favicon

Re: flattening continuation lines

Paul Fox wrote:
> i have what feels like a simple problem.
> 
> i want to post-process the output of mhbuild to add a "Content-disposition"
> header after any Content-type header that matches some criteria.

Wouldn't it be easier to just edit the C code? Out of interest, why do
you want to do this? Are you perhaps sending mail to someone whose mail
client doesn't like messages which lack the header? mhbuild probably
ought to handle Content-Disposition. The existance (or otherwise) of a
filename is perhaps a good way to select whether ot not the value should
be inline or attachment.

A quick one-minute hack at the C code is below. I've not searched out
the relevant rfc or anything so all this is is something to start with.
I suspect their are some situations (such as multipart parts) where you
don't want it, for example.

Oliver

Index: h/mime.h
===================================================================
RCS file: /cvsroot/nmh/nmh/h/mime.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 mime.h
--- h/mime.h	30 Apr 1999 18:08:34 -0000	1.1.1.1
+++ h/mime.h	18 Apr 2005 10:23:52 -0000
 <at>  <at>  -12,6 +12,7  <at>  <at> 
 #define	ENCODING_FIELD	"Content-Transfer-Encoding"
 #define	ID_FIELD	"Content-ID"
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Fox | 18 Apr 2005 13:58
Picon
Favicon

Re: flattening continuation lines

 > Paul Fox wrote:
 > > i have what feels like a simple problem.
 > > 
 > > i want to post-process the output of mhbuild to add a "Content-disposition"
 > > header after any Content-type header that matches some criteria.
 > 
 > Wouldn't it be easier to just edit the C code? Out of interest, why do

in general, i agree, and it was my first reaction, after seeing
that content-disposition has been on the mh todo list for a
number of years.  in this particular case, the changes aren't for
me -- they're for my wife, to use at work, where she's been
burned in the past by using local copies of stuff that is also
supplied by "IT", so i was trying to script the solution instead. 
in any case, your patch is a lot simpler than what i would have
come up with -- i probably would have duplicated much of the code
that lets one insert Content-Description headers, in order to let
the user specify Content-Disposition in a similar manner (with,
perhaps { } delimeters in the draft file.

 > you want to do this? Are you perhaps sending mail to someone whose mail
 > client doesn't like messages which lack the header? mhbuild probably

apparently people she works with can't tell her attachment types
apart easily -- so she wants her outgoing headers to look just
like the ones her co-workers send.  (they all use browser-based
mailers of some sort -- i assume netscape or IE.)

what i actually suspect is that specifying the name in the
content-type header would be sufficient (something she only just
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mick Farmer | 18 Apr 2005 16:50
Picon
Favicon

Show and OpenOffice.org

Hi,

When someone sends me a Word document (typically as an attachment) I
want to view it with OpenOffice.org.  I have the following in my
.mh_profile.

	mhshow-show-application/msword: %pooffice '%F'

OpenOffice.org starts, but then fails with the following error.

	signal 11 (segmentation fault)

Needless to say, if I unpack the parts using mhstore and view the
document everything is fine.  I'm running nmh-1.0.4-18.

--

-- 
Mick Farmer <mick <at> dcs.bbk.ac.uk>

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 0 comments |
headers
Oliver Kiddle | 19 Apr 2005 12:39
Picon
Favicon

Re: flattening continuation lines

Paul Fox wrote:

> in general, i agree, and it was my first reaction, after seeing
> that content-disposition has been on the mh todo list for a
> number of years.  in this particular case, the changes aren't for
> me -- they're for my wife, to use at work, where she's been
> burned in the past by using local copies of stuff that is also
> supplied by "IT", so i was trying to script the solution instead. 
> in any case, your patch is a lot simpler than what i would have
> come up with -- i probably would have duplicated much of the code
> that lets one insert Content-Description headers, in order to let
> the user specify Content-Disposition in a similar manner (with,
> perhaps { } delimeters in the draft file.

It would be good to have this working in the C code and it may not be
too hard. Has anyone got any good ideas on a syntax. Using { } isn't a
bad idea.

At a simple level we might have { attachment } and { inline } but what
should it do by default? And can we perhaps do something to avoid the
need to repeat the filename three times in this:

#text/plain; name="file.txt" { attachment; filename="file.txt" } /tmp/file.txt

I'd quite like to make it fairly intelligent by default. So:
  #text/plain /tmp/file.txt
would result in:
  Content-Disposition: attachment; filename="file.txt"
and you would need:
  #text/plain { } /tmp/file.txt
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Fox | 19 Apr 2005 15:14
Picon
Favicon

content-disposition (was Re: flattening continuation lines )

 > > come up with -- i probably would have duplicated much of the code
 > > that lets one insert Content-Description headers, in order to let
 > > the user specify Content-Disposition in a similar manner (with,
 > > perhaps { } delimeters in the draft file.
 > 
 > It would be good to have this working in the C code and it may not be
 > too hard. Has anyone got any good ideas on a syntax. Using { } isn't a
 > bad idea.
 > 
 > At a simple level we might have { attachment } and { inline } but what
 > should it do by default? And can we perhaps do something to avoid the
 > need to repeat the filename three times in this:
 > 
 > #text/plain; name="file.txt" { attachment; filename="file.txt" } /tmp/file.txt
 > 
 > I'd quite like to make it fairly intelligent by default. So:
 >   #text/plain /tmp/file.txt
 > would result in:
 >   Content-Disposition: attachment; filename="file.txt"
 > and you would need:
 >   #text/plain { } /tmp/file.txt
 > for no disposition header.

that sounds fine to me, but i don't consider myself an expert.

so basically, the entire text between the { } pair would fully
specify the Content-disposition header, but that unlike
Content-description (which has no default value), the
Content-disposition header would have a default value of
	attachment; filename="<file basename>"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Oliver Kiddle | 19 Apr 2005 15:54
Picon
Favicon

Re: content-disposition (was Re: flattening continuation lines )

Paul Fox wrote:
> so basically, the entire text between the { } pair would fully
> specify the Content-disposition header, but that unlike
> Content-description (which has no default value), the
> Content-disposition header would have a default value of
> 	attachment; filename="<file basename>"
> does that sound right?

Yes

In some situations (such as multipart parts), it would default to adding
no Content-disposition header and where there is no filename because the
content is specified inline, it would use a value of inline for the
header. I'll have a closer look at what other mailers produce.

Oliver

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 0 comments |
headers
Paul Fox | 27 Apr 2005 15:50
Picon
Favicon

tempfile creation


it seems that the usual paradigm in the nmh code (i'm looking at 1.1
source) for creating a temp file is to do something like this, from
mhbuild.c:

	/* copy standard input to temporary file */
	strncpy (infile, m_scratch ("", invo_name), sizeof(infile));
	if ((fp = fopen (infile, "w")) == NULL)
	    adios (infile, "unable to open");

invo_name at this point is "mhbuild".  m_scratch() adds some
randomness (via mktemp()), and opens the file.

a) i'm surprised the transition to mkstemp hasn't happened.  this
may feed into the reasons behind b), which is that since there's
no path associated with the temp file name, it's created in the
current directory.  if i don't happen to have write permission
there, mhbuild fails.  why aren't tempfiles created in /tmp?

paul
=---------------------
 paul fox, pgf <at> foxharp.boston.ma.us (arlington, ma, where it's 48.7 degrees)

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 20 comments |
headers
Mike O'Dell | 27 Apr 2005 17:01
Favicon

Re: tempfile creation


if i were to hazzard a guess, the reason the code doesn't use
mkstemp() is that [1] the code cited is likely well more than
twice age of mkstemp() [2]and nobody has gone looking for
things to fix that were still (apparently) working. (big grin)

the question about /tmp is probably related the security issues
and how difficult it has been to make /tmp files robust against
hijacking.

	cheers,
	-mo

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 19 comments |
headers
Josh Bressers | 27 Apr 2005 17:26
Gravatar

Re: tempfile creation

Mike O'Dell wrote:
> if i were to hazzard a guess, the reason the code doesn't use
> mkstemp() is that [1] the code cited is likely well more than
> twice age of mkstemp() [2]and nobody has gone looking for
> things to fix that were still (apparently) working. (big grin)

While it does work, mkstemp is far superior to mktemp in every way.
There's not a terribly good reason to not use it.  I've been looking at
how to best do this, but sadly the code needs serious cleanup first.
There is a lot of duplication, and it seems a lack of uniform error
handling when using tempfiles.

> the question about /tmp is probably related the security issues
> and how difficult it has been to make /tmp files robust against
> hijacking.

mkstemp should make it nearly impossible to hijack a file in /tmp.

--

-- 
    JB

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 0 comments |

Gmane