On Tue, Oct 4, 2016 at 8:57 AM, David Levine wrote:
> If not a tty, we're back to the question. Safer to fail, friendlier to
> decode.
Decode.
How often are real files with "=?...?=" in their name them encountered?
--ewh
___
Nmh-workers mailing
On Tue, Oct 4, 2016 at 7:44 AM, Ralph Corderoy wrote:
> Content-Type: inode/x-empty; name*=UTF-8''%41%00%42
> Content-Disposition: attachment; filename*=UTF-8''%41%00%42
>
> `mhstore -auto' creates `./A'. Perhaps the RFCs rule out %00? But then
> again, we're talking about crap that
On Wed, Sep 28, 2016 at 1:11 PM, Ken Hornstein wrote:
>>The question remains of whether mhstore should decode 2047-encoded
>>filenames natively. It'd be friendly and it's very unlikely that what
>>looks ike an encoded string isn't. On the other hand, running mhfixmsg
>>shouldn't be prohibitive.
On Wed, Aug 12, 2015 at 8:55 PM, Ken Hornstein wrote:
- Handle everything internally as UTF-8.
- For _display_, try to convert all of the characters to the native
character set (yes, using the locale, dammit!).
- For things like _replies_, if we are not in an UTF-8 locale then
downgrade
On 8/11/2015 11:33 AM, Ken Hornstein wrote:
Well, this works great if your locale is UTF-8. But ... what happens
if your email address contains UTF-8, and your locale setting is
ISO-8859-1?
Let me expand on this a bit, because I didn't explain it well.
Obviously if your locale is ISO-8859-1,
On Thu, Dec 4, 2014 at 5:28 PM, Lyndon Nerenberg wrote:
Oh gawd are we going to have the systemd bikeshed here, too? :-P
Why haven't you heard, there is going to be a systemd-nmh service ;)
--ewh
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
On Wed, Nov 12, 2014 at 11:49 AM, David Levine wrote:
Good points. All the more reason to wrap the opens + fcntl().
Popping in real quick here, but if we are voting on this, I prefer the
fcntl() route. I have a fairly old linux box that I still use nmh on.
It is running a v2.4.20 linux
On Tue, Oct 28, 2014 at 8:11 AM, Robert Elz wrote:
If the browser vendors cannot be convinced of the utility of providing a
command line switch to set the default char set (which can be passed through
to the actual browser that displays the page however they like) then the
only alternative to
On Fri, Aug 8, 2014 at 1:07 PM, Norman Shapiro wrote:
I could try to install a google-chrome package from Fedora. But that is kind
of chancy, and Google Chrome 27.0.1453.110 is working well enough for me. A
spurious  or two is a pretty minor annoyance.
Have you looked into Chromium instead?
On Wed, Jul 30, 2014 at 5:25 AM, Ralph Corderoy wrote:
Would be much nicer if it travelled internally as UTF-8 and then popped
into the US-ASCII draft as
Subject: Re: =?utf-8?B?wqE=?=Hola world!
and into the UTF-8 draft as Re: ¡Hola world!.
But this behavior does not require the data
On Wed, Jul 16, 2014 at 12:15 PM, n...@dad.org wrote:
ASCII was good enough for my father and his father before him, and his father
before him. The tablets that Moses brought down from Mount Sinai, were in
ASCII, as were Newton's Principia, the Magna Carta, and the United States
Declaration
On Wed, May 14, 2014 at 9:38 AM, Ken Hornstein wrote:
- This part is text/plain
- There is no final newline
- You are running mhshow (I only mention this because mhstore uses some
routines in mhshow, including the one that I want to modify, but it's
easy to tell when the caller is
On Wed, May 14, 2014 at 3:27 PM, Paul Fox wrote:
If you specify a disposition of
attachment (which we do), you can't complain about gmail doing what you
told it.
au contraire. i can certainly complain, which is what i did. and now
we're talking about how to fix it.
Since the
On Tue, May 13, 2014 at 10:16 PM, Ken Hornstein wrote:
I am unclear as to the right solution. Obviously adjusting the MIME
parsing routines is wrong. Making sure that the last character of
text/plain parts on output contains a newline might be better, but I'm
not sure that's technically
the
problem was never discovered before is beyond me (likely since attribute
parts are rarely used in the wild).
I've already been in communication with Earl Hood (the author of
MHonArc) who confirmed the issue, and he's developing a fix right now.
I don't know when that fix will make
On Sun, Apr 20, 2014 at 9:35 PM, Ken Hornstein wrote:
I don't look at the headers of every message I get, but I did check my
mailbox for examples when I was writing the RFC 2231 parser. I have
never seen an extended MIME parameter on a Content-Type header in the
wild, but I do see them all
On Tue, Apr 15, 2014 at 3:00 PM, Ken Hornstein wrote:
I have mixed feelings about this; I think /bin/bash is wrong, but I thought
that /bin/sh should actually work everywhere. I know perl is all over
the place, but I thought /usr/bin/perl was pretty standard. What do
others think?
/bin/sh
On Mon, Apr 14, 2014 at 10:28 PM, Lyndon Nerenberg wrote:
I think in 1.7 we need to deprecate the POP support. And in 1.8
deprecate the submission SASL support.
-1 on deprecating SASL support. I use it.
I use delegated on my LAN, where my local systems can submit mail to it
using SASL, and
On Mon, Apr 14, 2014 at 11:14 PM, Lyndon Nerenberg wrote:
-1 on deprecating SASL support. I use it.
Out of curiosity, which mechs?
What's this have to do with anime? :)
If you mean operating systems, my router/relay system is an old linux
box (pre RHEL release) running on a 15+ year old
On Sun, Apr 13, 2014 at 7:55 PM, Lyndon Nerenberg wrote:
Either you upgrade the top-level encoding, or you downgrade the
encoding of the encapsulated message/rfc822.
Correct, with the former likely the preferred method unless you know
that the transport/delivery systems has problems with 8bit
On Wed, Feb 19, 2014 at 1:33 PM, Lyndon Nerenberg wrote:
As for disk space, how much you use is a function of the types of
email you receive and how much of a pack rat you are.
Yep. Ages ago, if one had a ton of email, you may have issues of
running out of inodes, but I do not think that is
On Wed, Feb 19, 2014 at 1:44 PM, Paul Vixie wrote:
i would. first, i'd adopt the messages-as-directories model norm gave,
since it supports MIME, where our current model does not. by support
i mean i want to use normal UNIX file access to work with my message
store. there is no file-level
On Thu, Feb 13, 2014 at 1:56 PM, otahler wrote:
I knew already that Sylpheed/Claws Mail used the MH system, as they are
sitting on top of it. But now I was bit suprised to hear that they are just
a GUI, because I thought of them as much more than a GUI. Just out of
curiosity: do Sylpheed/Claw
On Mon, Feb 3, 2014 at 12:46 PM, Robert Elz wrote:
No, and I wasn't arguing against using mkstemps() where it is available,
just against using link() in preference to rename() - that one makes no
sense.
| mkstemps() first appeared in OpenBSD 2.4.
Oh, OK, given all those systems, I guess
On Sun, Feb 2, 2014 at 4:43 PM, David Levine wrote:
Documented where? SUSv3 calls out the behaviour explicitly, as
inherited from the ISO C spec.
Well, the SUSv2 spec says:
If the link named by the new argument exists, it shall be removed
and old renamed to new. In this case, a
On Fri, Jan 31, 2014 at 12:50 PM, Ken Hornstein wrote:
Right now if the text parts contain any 8bit or long lines ( 76
characters) the content is forced as quoted-printable. Obviously with
a default of 8bit, 8bit characters are fine. But should lines 76 be
8bit, or q-p? I'm unsure which
On Mon, Jan 13, 2014 at 9:17 PM, Jon Steinhart wrote:
I've noticed that when you run
attach with -attachformat 0, you get a x-unix-mode MIME parameter.
My question is: why?
Jon did it that way originally, I don't know why. I needed
a different format, with a Content-Disposition. When I
On Mon, Jul 15, 2013 at 12:39 PM, Ronald F. Guilmette wrote:
This all suits me and my preferences perfectly. The only problem
is that I have only been able to figure out how to arrange for
MH to invoke my little mtext filter/reformatter *only* for
cases where I am doing a show operation. I
On Mon, Jul 15, 2013 at 2:28 PM, Ken Hornstein wrote:
replyfilter gets hooked into mhl as part of step 2) above. replyfilter's
magic is new functionality in mhl that allows the body component of a
message (basically, the whole body as one big piece) to be processed via
an external program.
I
On Wed, Jun 26, 2013 at 4:11 PM, n...@dad.org wrote:
After all, if a person is smart enough to use nmh,
they're smart enough to figure out how to fix a header line, right?
I hope and believe that a person does not have to be unusually smart
to to use nmh.
Maybe it is better to say:
The
Checking the nmh source code (and the old MH source code), it seems
to me that if I show a message, but redirect to a file, MH/nmh will
try to auto-fetch a message-external/body part (e.g. anon FTP).
Am I correct in my reading of the code?
Or, is it the case that any message-external/body part
On Fri, Feb 8, 2013 at 2:41 PM, Ken Hornstein wrote:
Checking the nmh source code (and the old MH source code), it seems
to me that if I show a message, but redirect to a file, MH/nmh will
try to auto-fetch a message-external/body part (e.g. anon FTP).
Am I correct in my reading of the code?
On Wed, Dec 5, 2012 at 2:48 PM, norm wrote:
I send text/plain with lines no longer than 72 and blank lines between
paragraphs.
That's what I had been doing for years. And I did get complaints.
It is an exercise in futility to deal with MUAs that do not following
the specifications. Text/plain
On Sat, Nov 3, 2012 at 12:14 AM, Lyndon Nerenberg wrote:
Pretty much every modern terminal (emulator) supports color, so more
power to those that want to do add color to scan output.
But is it worth the added code complexity?
But that is not what the initial criticism was about, unless I
On Tue, Sep 11, 2012 at 2:10 PM, rader wrote:
LOGABSTRACT=yes with procmail-3.22-17 (RHEL/SL) only gets me Subject and
Folder. Is there a new version around I didn't find?? (I only glanced
and saw 3.22 and a msg to the ML bounced.)
You are right. You have the From line added by the
On Mon, Apr 16, 2012 at 12:27 PM, Lyndon Nerenberg wrote:
Updated Estimate: .3,141.00
Updated Estimate: ?3,141.00
Presumably there is a loud warning being printed to say ***danger
corrupt message - unprintable characters replaced with '.'
Such warnings can be easily overlooked
On Mon, Mar 12, 2012 at 11:05 AM, Lyndon Nerenberg wrote:
I would prefer to build these non-822 directives using a syntax that can't be
confused with a valid 822 header. I suggest the format:
metahead = . directive *(SP params)
directive = LETTER *(LETTER / DIGIT / -)
params = ;
On Tue, Feb 14, 2012 at 1:23 PM, Ken Hornstein wrote:
Okay ... so now that's been cleared up :-)
Do people like the idea of:
- A dedicated function %(localmbox)
- A pseudo component %{localmbox}
- Extra primitives to build the default local mailbox (%(myname), %(myhost)).
If you go with a
On Tue, Feb 7, 2012 at 11:29 AM, Lyndon Nerenberg wrote:
But do you really think that
should be the only resort when badly formed mail arrives? I'd prefer to
see what was intended by the sender.
Yes, I do :-( QP and Base64 (and MIME in general) have been around for
nearly two decades
On Mon, Feb 6, 2012 at 12:51 PM, Joel Uckelman wrote:
If/when IMAP support is added in, mhpath will return
imap URLs. If one is using the existing classic storage
model, then local pathnames are returned.
IMAP URLs aren't paths, at least not in the sense I take 'path' to have
in 'mhpath'.
Wrt to mhpath, I think it is getting over analyzed. All
mhpath does is provide the *path* to an nmh resource,
that's it.
Issues like fetching or not fetching are out-of-scope.
If/when IMAP support is added in, mhpath will return
imap URLs. If one is using the existing classic storage
model,
On Fri, Jan 13, 2012 at 8:24 AM, Ken Hornstein k...@pobox.com wrote:
Apparently, CentOS 5.7 version of autoconf is older than
what the nmh build process says is required. CentOS 5.7
provides autoconfig 2.59 but nmh is configured to require
2.61 and later.
I just looked ... and autoconf 2.59 was
I have not compiled from source in sometime, but want to
try out the latest changes, but hit a snag with running
autogen.sh.
Apparently, CentOS 5.7 version of autoconf is older than
what the nmh build process says is required. CentOS 5.7
provides autoconfig 2.59 but nmh is configured to require
On Thu, Jan 12, 2012 at 11:02 PM, Earl Hood wrote:
I have not compiled from source in sometime, but want to
try out the latest changes, but hit a snag with running
autogen.sh.
Apparently, CentOS 5.7 version of autoconf is older than
what the nmh build process says is required. CentOS 5.7
On Tue, Jan 10, 2012 at 4:56 AM, Ralph Corderoy ra...@inputplus.co.uk wrote:
Hi Earl,
%(lit)%(formataddr %{reply-to}%?{from}%?{sender}%?{return-path}%)\
%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
%(match example1.com)From: e...@example1.com\n\
%?(match example2.com)From:
On Tue, Jan 10, 2012 at 2:19 PM, Ken Hornstein k...@pobox.com wrote:
Ow. Damn your eyes, Earl ... I now have a headache from staring at the
damn mh-format code.
I'm glad you decided to look at the code since I was not
looking forward to it myself.
But, on the upside ... I figured out the
On Mon, Jan 9, 2012 at 12:39 PM, Paul Fox wrote:
(i just checked, and realized that i'd be affected -- i have scripts
that sometimes munge the draft to create a From: header based on current
folder, and i see by the way i wrote them that there's an assumption
that there's no such header by
On Mon, Jan 9, 2012 at 9:05 PM, Ken Hornstein wrote:
I do the same thing as you, and I would like the same thing. There are
technical issues (you don't normally have access to the identity you received
the message at when repl gets it), but we could at least make it work
better than we do
On Thu, Jan 5, 2012 at 10:55 AM, Ken Hornstein k...@pobox.com wrote:
I've noticed that there are a number of places that are #ifdef UCI.
They turn on various random things (like, if you have a file called
.signature in your home directory, it will use it as the signature
entry in your
On Fri, Dec 9, 2011 at 5:25 PM, Jeffrey Honig j...@honig.net wrote:
I have my fetchmail scripts ignore messages with a duplicate messageid
(using a history of messageids I've received during the last 30 days or so)
to avoid duplicate mail.
Depends on what you mean by duplicate. From a mail
On Fri, Dec 9, 2011 at 9:29 PM, Ken Hornstein k...@pobox.com wrote:
I thought about breaking up the MIME parts, but I decided that the
problem with that was that I believe there is value to still having the
original message around.
Just think of SMIME, PGP, DKIM, et.al. Preserving the
On Tue, Feb 8, 2011 at 1:26 PM, Paul Vixie vi...@isc.org wrote:
format=flowed is now considered as the implicit default by some readers
notably apple's Mail.app, because so many senders use the format without
saying so in their mime headers. MH needs to adapt to current conditions.
I have
On Sun, Dec 5, 2010 at 9:34 PM, chad wrote:
On Dec 5, 2010, at 6:52 PM, Earl Hood wrote:
I do something like the following:
fetchmail -m '/usr/bin/procmail -d %T'
I used to do this, and have procmail do crude spam filtering.
I eventually took it out of the loop because mail spool
On 12/1/10, Jon Steinhart wrote:
Maybe I don't understand your proposed changes. Apologies if I get this
wrong;
I didn't save a copy of your original email and the archives are currently
down.
FYI, I've had a nmh list archive running for some time,
as an alternative to what savannah
On Sun, Nov 21, 2010 at 12:37 PM, Ken Hornstein k...@pobox.com wrote:
The way every other autoconf package works is that when it gets done, it
results in a Makefile that sets CPPFLAGS and LDFLAGS appropriately, It sounds
like what was done here was create a situation where you have to say:
export
On Sun, Nov 14, 2010 at 11:45 AM, Jon Steinhart j...@fourwinds.com wrote:
My preference is to say that we'll treat any =?...?= as an encoded word
wherever it appears and that we'll decode it. It appears that the authors of
RFC2047 expect that everything will be parsed into tokens and examined
On Sat, Nov 13, 2010 at 11:50 AM, Jon Steinhart j...@fourwinds.com wrote:
Look at the $LANG environment variable, that's probably a good start on most
systems. The various LC_ environment variables if you want to do more
localization work.
That's the way it is on my Linux system but that
On Fri, Nov 12, 2010 at 8:08 PM, heym...@bellsouth.net wrote:
The question that still out there is whether or not nmh should support
smtps. If so, I'm more than willing to go back into the code and work
on it. Would this be of interest? What kind of schedule are we looking
at for nmh 1.4
On Fri, Nov 12, 2010 at 9:50 PM, Jon Steinhart wrote:
I haven't paid attention to mail standards in a long time. Is RFC 2231
a happening thing? Do we need to go through the trouble of supporting it?
I have support for 2184 (which 2231 updates) in my
OSS Perl program, but mainly when dealing
On Fri, Nov 5, 2010 at 4:48 PM, markus schnalke mei...@marmaro.de wrote:
So send should:
* check for non-ASCII characters
* when present: pick an encoding (first usable one from
a user-configurable list like us-ascii,iso-8859-1,utf-8)
* encode body and headers as per MIME, adding MIME
On Thu, Nov 4, 2010 at 9:37 PM, Simon Burge sim...@netbsd.org wrote:
Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
Do any of you have a pristine 6.8.4 source distribution lying
around, or know of a current online archive? It'll take me
weeks to figure out which set of archives my copy is in.
On Wed, Feb 3, 2010 at 2:58 AM, Peter Maydell
pmayd...@chiark.greenend.org.uk wrote:
Earl Hood wrote:
Even though no one has convinced me that my new functions
still contain the race condition security problem,
There was a URL in the old linked message I provided;
the problem
On Wed, Feb 3, 2010 at 12:20 PM, Sean Kamath wrote:
Frankly, people who run tmp cleaners that are that braindead probably
deserve what they get.
Are we to worry about braindead temp cleaners? I.e. I'm
sure other apps would have problems with braindead
cleaners, so should we waste resources
On Wed, Feb 3, 2010 at 12:30 PM, valdis.kletni...@vt.edu wrote:
If the calling code did not immediately use the temp file,
the new functions close the descriptor returned from mkstemp(),
but it does NOT delete the file.
Since the file still exists, an external (different uid) process
On February 3, 2010 at 15:23, valdis.kletni...@vt.edu wrote:
Given that the vast majority of nmh users are probably on laptops or
single-user desktop boxes rather than large central servers with untrusted
other users on them, and your code *is* an improvement, I think the best
thing to do is
On Wed, Feb 3, 2010 at 5:59 PM, Sean Kamath wrote:
My real point was that it should be configurable, which you've done.
Slightly odd to make it an env variable than an nmh setting in
.mh_profile, but whatever.
It's easy to add .mh_profile check, but not all
commands read the profile (e.g.
On Wed, Feb 3, 2010 at 8:06 PM, Chad Brown yand...@mit.edu wrote:
I don't know that anyone cares, but POSIX says ``TMPDIR'':
Recent commit uses the following, in order:
*MHTMPDIR envvar
*TMPDIR envvar
*TMP envvar
*User's mail directory.
--ewh
Attached are the changes I have currently done in my development
environment. The changes also include minor mods to deal
with may be uninitialized warnings from gcc.
I added a new file, sbr/m_mktemp.c, to include the new functions for
replacing m_scratch() and m_tmpfil().
The goal was to
On February 2, 2010 at 22:26, Peter Maydell wrote:
Yes, this is why it's difficult to fix :-). Unfortunately, if you
use mkstemp() but still allow the rest of the code to reopen
the temporary file by name, you've shut the linker up but
not completely closed the security hole. See
On February 2, 2010 at 15:45, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
Having an MH-private namespace for scratch files is certainly the way
to go here. These aren't 'temp files' in the traditional sense, and
none of the usual APIs suit the task at hand.
Actually, we have complete control of
On February 2, 2010 at 13:40, Earl Hood wrote:
Attached are the changes I have currently done in my development
environment. The changes also include minor mods to deal
with may be uninitialized warnings from gcc.
Found a problem with mhparse.c with the changes I did. Temporary files
can
On February 1, 2010 at 22:06, Ken Hornstein wrote:
I looked over your patches; I say commit 'em (I'd personally prefer that
nmh had inline TLS support,...
I agree, but the changes are also applicable for any non-TLS mail
server that requires SASL.
The horse has definitely been pounded to
I find it annoying that I have to replicate command-line options
for 'send', 'push', and 'whom' because post does not consult
the .mh_profile file.
For example, if you use sasl, I have to specify the same set of
sasl arguments multiple times:
push: -unique -sasl -saslmech LOGIN -user user
On January 30, 2010 at 10:49, Lyndon Nerenberg wrote:
Not sure how it worked since SASL support is not available
when using sendmail as your mts delivery method. I.e. If
the SMTP server requires user/pass authentication, sendmail-based
deliver will not work.
Sendmail has had SASL
On January 29, 2010 at 23:01, Ken Hornstein wrote:
If your interest is to only exchange messages with other
nmh users, then I guess you won't care ... but I would suggest that
if nmh doesn't evolve, at some point there won't be any other nmh
users.
I agree.
For years, I have used a separate
On January 29, 2010 at 11:36, markus schnalke wrote:
What exactly do you mean with ``users''? If you mean people that are
no programmers, then I agree. If you mean us, then I don't.
I consider non-programmers. If not, nmh will just be a nitch
MUA, and probably over time, die a slow death.
On January 28, 2010 at 11:04, markus schnalke wrote:
Use a simple forwarding MTA (like nullmailer or ssmtp) instead.
Has anyone got either of these programs to work with nmh?
If so, can they share their configuration?
IIRC, ssmtp is a command-line replacement of sendmail vs
running as a
On January 28, 2010 at 10:39, Ken Hornstein wrote:
Fetching mail is also the job of a different tool.
So, just so we're clear ... you want to remove the existing support for
POP in inc as well?
I agree with Ken.
At some point, nmh must be able to read (incorporate) mail to
do its job.
On January 22, 2010 at 11:02, Stewart W Wilson wrote:
I tried the patch given by Valdis Kletnieks
http://lists.gnu.org/archive/html/nmh-workers/2004-08/msg8.html
I changed smtp.c (in nmh1.3) as he said to do.
But it didn't work. The no servers available error didn't occur,
but this time
On January 22, 2010 at 16:26, Ken Hornstein wrote:
The port 25 block is pretty much standard for large ISPs today; it's
to prevent spammers from using massive networks of compromised PCs to
deliver spam.
Changing ports is useless unless authentication is required.
If deterring spammers is the
On August 18, 2009 at 11:33, bergman wrote:
I use procmail to automatically file incoming mail into different folders,
using rcvstore. This works very well, but rcvstore changes the default folder
.
According the the rcvstore manpage, the context should not be
affected:
CONTEXT
No
On July 4, 2009 at 10:43, Bill Wohler wrote:
I'd like to start synchronizing my MH aliases with the contacts in my
phone and Google contacts.
Has anyone given any thought to this?
Looks like Google has a CSV format that can import/export, so
some little scripting can be done to map MH
On Sun, Jan 25, 2009 at 9:17 AM, Joel Uckelman uckel...@nomic.net wrote:
I think the cut-off is more likely to be gen-Xers than baby-boomers.
MH used to be the default MUA at MIT until ~2000, which is where I picked it
up.
I left UCI in '93, and of course, it was the default MUA on many
On Mon, Sep 15, 2008 at 11:12 PM, Bill Wohler [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I started to use Bill Wohler's mhfinddup script[1] to delete the
duplicates
It may not matter, but attached is a Perl script I wrote some time ago to
check for message duplicates. Probably
On October 1, 2007 at 11:10, Martin McCormick wrote:
I moved my mail base of operations from one system to
another and installed the latest version of mhonarc, still using
the configuration files I had used on the slightly older system.
I started to reply to a mime message and got the
On March 6, 2006 at 18:44, Bill Wohler wrote:
Earl Hood [EMAIL PROTECTED] writes:
I recommend discard. Spammers are known to use originating addresses
of regular people, so you can potentially be the cause of receiving
more spam due to mis-directed bounces.
Unfortunately
On March 7, 2006 at 15:12, Ralph Corderoy wrote:
I recommend discard. Spammers are known to use originating
addresses of regular people, so you can potentially be the cause of
receiving more spam due to mis-directed bounces.
But Mailman is generating a `your message is pending approval
On December 26, 2005 at 16:10, Igor Sobrado wrote:
Indeed, I missed that important matter. Certainly nmh should follow
standards as nicely as possible. It does not make sense violating
a RFC only because a product (in this case, the email filtering service
provided by Postini) does. I was
On November 23, 2004 at 17:39, Arun Bhalla wrote:
In addition, like many of you, I'm sure, I have to read and respond to
emails containing text/html parts. Reading isn't so bad since I just
pipe it through lynx in my .mh_profile, although sometimes I'd rather
have it default to text/plain
On September 16, 2004 at 17:20, Harald Geyer wrote:
Is there any sort of wish list for nmh development?
There are a number of issues in the TODO list. I don't know who
maintains it though. I feel most important is better mime support
... and of course cleaning up the code.
Savannah
.
Best Regards
Cameron
From: Earl Hood [EMAIL PROTECTED]>
Date: 14 September 2004 07:34:11 BST
To: [EMAIL PROTECTED]
Subject: Re: NISCC Vulnerability Advisory 380375/MIME
Reply-To: Earl Hood [EMAIL PROTECTED]>
NISCC,
Your advisory mentions the existence of a MIME test suite, which
some vendor
I've set up an alternative list archive at
http://www.mhonarc.org/archive/html/nmh-workers/.
There is currently no direct link to the archive on the All Lists page.
Another user on the list stated he has list message back to 1992,
so when I am able to get a copy, I can import them into the
92 matches
Mail list logo
