[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
From: |
David Levine |
Subject: |
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option? |
Date: |
Tue, 31 Jan 2006 20:22:47 -0500 |
> > Nice. Attach already takes the filename. Options would need to
> > include mime-type, name, mode, description, and Content-ID. Anything
> > else? If there's too much, it would get unwieldy.
> >
> > Any suggestion on how to associate the option values with the build
> > directive? printf style?
> >
> > whatnow: -attach X-MH-Attachment='#%T; name="%N" <%C>[%D; %M] %F'
> >
> > whatnow? attach -mime-type=application/wierd -name=foo -mode=0x640 -descr
> iption="my app" -contentid="" /tmp/foo
> >
> > If any value in the build directive isn't specified, it
> > would be determined automatically (using mhshow-suffix for
> > the mime-type as it is now, and getting the name from the
> > filename, and so on).
> >
> > While that example has a lot of typing, its purpose is to
> > show all the options. I expect to rarely specify options,
> > given a suitable build directive, such as '#%T; name="%N"
> > <>[] %F', with the mime-type and name usually determined
> > automatically. I don't see a need to bother with mode or
> > description, and don't want contentid.
> >
> > It might be possible to add support for Content-Disposition
> > here.
>
> Um, gimme a break here. Why not just use mhbuild mime-composition files?
I've been doing that for years, with help from emacs
functions and key definitions. Even with that support, I
still made a copy-and-paste error last week. And not the
first time.
> I added the attachment handling code so that non-geeks could send attachments
> .
> This is heading in the opposite direction. How often are these cryptic
> arguments really going to be used? How many other mailers care about this
> sort of stuff? How many mail programs even look at this stuff?
While it may not be obvious :-), I want simple, as well.
And more foolproof. But I also want configurable. I know
that I would never use any of the command line options
above. Maybe I should just not bother with them.
The one thing I do want to be configurable is the build
directive. Again, it's not something that I'll change, so
it can go into my .mh_profile. But, what's the best way to
communicate it (currently it has three pieces) to
make_mime_composition_file_entry ()?
> If you decide to make these additions, keep in mind that they have to be done
> in the send code, not in the whatnow code. This is because the design of the
> attachment code was such that it would work independent of the user interface
> .
> In particular, I know people who have hacked mh-e to add attachment headers.
Got it. It's easier given nmh's current state, as well.
David
- Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?, (continued)