cifically,
support for APOP, RPOP, NNTP (including bboards) and MPOP is now gone.
Also gone is support for prefixing a \01 in the "servers" entry in mts.conf
to iterate over all servers on a named network.
Feedback (including bugs) should be directed to the nmh-wo
>Over the holidays, I replaced my 15-year old mail server (two hardware
>generations, three / disks, upgraded from NetBSD 0.9...) with a new
>install based upon Postfix and Cyrus. But, I think I made the wrong
>choice in Cyrus. I should have gone for another IMAP daemon, one that
>stores in eithe
>So I had occasion to post an email that contained a data file, about 1M in
>size, averaging maybe 15 bytes/line (it was basically e-mail addresses from an
>extract, one per line). I hit 'send', and I'm watching gkrellm report 300K/sec
>going out my cable connection to our mail hub.. and after 3 s
>So I had occasion to post an email that contained a data file, about 1M in
>size, averaging maybe 15 bytes/line (it was basically e-mail addresses from an
>extract, one per line). I hit 'send', and I'm watching gkrellm report 300K/sec
>going out my cable connection to our mail hub.. and after 3 s
Greetings all,
I've just pushed to master all of the relevant changes that I've cherry-picked
from Lyndon Nerenberg's posix branch (other than Makefile changes, the only
ones I didn't do was one creating definitions for NI_MAXHOST and NI_MAXSERV
since we're not compiling strict POSIX, and one assu
Greetings all,
I am pleased to announce that nmh is now installable via MacPorts;
if you use MacPorts & pull down a new ports tree, you should be
able to do a "port install nmh" and the right thing should happen.
If you're unfamilar with MacPorts, you can read more at
http://www.macports.org.
If
So I've been looking at removing crud in nmh's autoconf support and mass
of #ifdefs, and I came across the --enable-mhe option.
This defines MHE during the build, and it enables a few bits of MHE
support (some commands get a -build switch, and inc does some extra stuff).
The default has been to b
>The code in inc.c, rnf,cm folder_read.c and mh-profile.man is some audit
>log stuff not used by mh-e (special audit file).
>
>The -build option in forw.c and repl.c *are* used by mh-e. The
>documentation for those flags would need to be cleaned up.
Okay, I can work with that. Thanks for looking
>> If someone wanted to turn the crank to update the RPMs used by a number of
>> Linux distros to 1.4, that sure would be cool (hint hint :-) ).
>
>How are the debs maintained for Ubuntu and Debian? It would be good to
>make sure they track our (your!) hard work.
I'm not sure how that works; does
In the "garbage collect old crap" vein ...
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 context). You would have had to turn
>uip/send.c and uip/whatnowsbr.c: auto-append .signature file when sending
>This is probably Bad and Wrong, because if you're sending a MIME
>message (like this one), the appended text will end up outside the
>MIME boundaries and thus not displayed by the recipient MUA. Should
>be heaved over the
Alright, in preparation for finally cleaning up our suboptimal autoconf
mess, I am tackling acconfig.h (a template which users can edit to
change defaults). My feeling is all of that should either be controlled
by autoconf or we take a decision on whether or not to keep or remove
that code. Here
>> REALLYDUMB - What this does is prevent adrsprintf() from appending a
>>local hostname if a username doesn't have one. You know,
>>I really think this should be a run-time option instead.
>>Anyone care if I make it so it is? (The default can
>>
>appending a local host name is almost always the wrong thing to do. let
>the MTA fully qualify stuff if the next-hop isn't another local mailbox
>(or even if it is). this is policy, and does not belong in the user agent.
Okay, I'm starting to remember what I used REALLYDUMB for in the past.
If yo
>Wasn't there discussion about removing the BBoard stuff, or am I
>confusing that with NNTP support? If the former, then msh and vmh would
>go with that, wouldn't it?
There was some discussion of removing BBoards and NNTP ... over a year
ago :-) I removed it from the source code on December 9th,
>nmh 1.4 is out. I hope you have some time soon to package it up.
>
>Could you please comment on Ken's questions about the following
>configuration items? Since I like the way you configure nmh on Debian,
>I'd like to ensure that his suggestions are consistent with the way you
>configure nmh. Thank
>Okay, I'm starting to remember what I used REALLYDUMB for in the past.
>If you don't supply ANY From header, REALLYDUMB controls what the From:
>line looks like. Normally that only happens in a few weird circumstances
>(but the default forward templates do that, for instance). It also
>ends up a
>Rather than guess, we should treat the absence of a From: header in an
>outgoing message as a configuration error and abort the send. This
>change makes the creation of a components file with a 'From:' header
>mandatory; the code that initializes the Mail/ folder should probably be
>extended to pr
>> >Rather than guess, we should treat the absence of a From: header in
>> >an outgoing message as a configuration error and abort the send. This
>> >change makes the creation of a components file with a 'From:' header
>> >mandatory; the code that initializes the Mail/ folder should
>> >probably be
>Why not have a check in send/post that if the From: header
>is missing, it reports an error and aborts the operation?
That's clearly one of the things we have to do.
But there are some things to do that aren't so obvious. Like, what do we
do about setting up someone's default component file? I
>I propose quite the opposite: Why not install sane components
>files on installation but still allow users to rely on header
>rewritting if they like to?
Okay, here's my question to you: the draft file has a completely nonexistent
From: line. What do we use as the From line in the message, and w
So, I am cleaning up more autoconf cruft, and one remaining thing
is the OS-specific defines. I don't think anyone will object to
the removal of SCO_5_STDIO specific code, but there is one that is
used a surprising amount: BSD42.
This code has two purposes: if you have a & in the GECOS field, it
>It seems that Lyndon is arguing that it would be better to just have
>From: lambda
>to prompt the MTA to rewrite the header. I just tried to send a message
>like that and it worked, but nmh added a
>Sender: lam...@a.g4.wien.funkfeuer.at
>line, which it doesn't do in the other cases. So likely t
Here is my $0.02 on this topic:
- Lyndon is completely correct in assessment of how email has changed; like
he says, nmh is based on how things used to be. It's time we dealt better
with the new world order.
In that vein, here's what I propose for future changes:
- We supply all of the comp
>Now, if nmh had the ability to preset the From: based
>on which identity I received the message under... Definitely
>a feature I like about Gmail since there are 3 identities
>I work under on a daily basis.
I do the same thing as you, and I would like the same thing. There are
technical issues
>Let me posit the idea of incorporating lua into the message processing
>stream. Both incoming and outgoing. As a header rewrite and message
>routing tool, it kicks the living daylights out of sieve.
Back when I first thought of it I had thought of using Tcl to do
it. But you know what? At the
>It's already fairly easy to do this with replcomps:
>
> From: %<{X-Envelope-To}Tethys %{X-Envelope-To}%|Tethys
> %>
>
>That relies on some sendmail.mc config to add an X-Envelope-To header
>to my mail on the way through:
So all I have to do is get Google to change their entire server
confi
>Errr... no. This has nothing to do with lack of capabilities in nmh.
>I use the envelope addressee because it's the canonical source of
>data that tells you to whom the message was addressed. But if it's
>not available, then no amount of work done by nmh can compensate
>for the missing data. In th
>Yes, that works, but as I noted, when in a replcomps, further
>attempts to access {to} and other components return empty
>values.
Ow. Damn your eyes, Earl ... I now have a headache from staring at the
damn mh-format code.
But, on the upside ... I figured out the issue here.
The problem is not
>I'm currently using Claws Mail as my principle interface to nmh, largely
>for threading and some other interface improvements vs. exmh. One huge
>'win' of Claws Mail over bare nmh is that it makes the selection of
>identity (From:, Reply-To:, Fcc:, signature) very simple when composing a
>new mess
>I'd like to see the addition of a new mh-format function "%(printf)".
>
>Building and customizing message parts using "%(putstr)" somewhat
>works, but is seriously ugly, because %(putstr) compresses repeated
>whitespace within a string and doesn't parse printf formatting such as
>"\n".
In theory,
>I would assume that if I use %(lit) to clear the str buffer, it
>should clear the cache.
Well, it's not like this is documented anywhere, so I think we're in uncharted
territory :-)
>This may be acceptable. I'm not sure if there are components files
>that depending on the caching, even after %(
>Rather that adding code to fiddle with the cache, potentially breaking things,
>and in any case, making it even harder to use mhl-format than it is now,
>I'll suggest an alternative solution.
>
>Split the implementation of formataddr() into two parts, one which does
>what its name suggests now, an
>allowing for very general purpose substitution lets the user use
>almost any tool they want to do their scripting -- if mh forgets to
>provide some parameter the user needs (time of day? is it a holiday?
>am i on my laptop?), then they still have access to that information
>via external mechanis
Hey, it seems to me that "dist" is broken in 1.4. Is that true for
everybody else? (I confess that I missed it because I so rarely
use it; I got a bug report from my wife about it). If it is really broken
for everyone else, is it worth releasing a 1.4.1? (I just committed a fix).
--Ken
__
Staring at the code for fmt_compile.c ... it seems like there's some support
for looping in the format code (%[...]), but I don't believe it's documented
anywhere. Anyone have any idea how it's supposed to work? Or even it it
does?
--Ken
___
Nmh-worke
Alright, I've meditated on this for a while, and I went back and read
Robert Elz's and Earl Hood's arguments carefully. And ... I found myself
more persuaded by Robert's arguments than Earl's (sorry, Earl).
To that end, I've just pushed some code to master that implements
the %(concataddr) functi
>You are the only person with the fortitude to go near that code lately,
>so all I can say is 'please document the new regime' ;-)
Well, the new functions are documented in the mh-format man page, and I
even put in the bits about repl's duplicate supression for formataddr
since that was news to me
>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 released in 2003, autoconf
2.61 was released in 2006. Yikes, I th
>I use dist regularly. However, I use the installed version of nmh in
>Debian. So for me, and others using a stable version of nmh, as long as
>the update appears before the (fill-in-the-blank) distribution releases
>nmh, you're good.
I guess I was kinda hoping that others would confirm that dist
Earl Hood mentioned that he was running into problems with "repl"
hanging, and I ran into the same thing as well during some testing
here, so I went and tracked down the problem. Basically, it boils
down to the use of %(putaddr) when "num" is zero.
%(putaddr) uses the "num" register as a field wi
>I think the %[...%] is by âJLRâ? do_loop() sets up an FT_DONE that's 1
>rather than the normal 0 and then the end of fmt_scan() at finished:
>checks if it's true and if so returns the next format instead of NULL,
>but only #ifdef JLR. Without that defined it appears to be ignored so
>formatt
>> But how would you exit the loop, that's what I don't understand.
>
>Me neither. I was hoping a caller that bothered to check for a non-NULL
>return would explain but didn't notice one. Is JLR still around?
He posted to nmh-workers a year ago, but I don't know how much he keeps up
with what's
>mh-format says this:
>
> When a function or component escape is interpreted and the result
> will be immediately printed, an optional field width can be
> specified to print the field in exactly a given number of
> characters.
>
>Note the text, "optional field width." Thus,
I finally remembered this ... all of the great cleanup work that
David Levine has been doing jogged my memory about something I
wanted to bring up a little while ago.
We use the utmp functions a bit (getutent() and the like). Those aren't
part of POSIX, but the utmpx functions are (getuxline() an
>Guess it will take a while before better mime handling is implemented.
Not necessarily.
So, I have some thoughts in this direction, but I'm wondering: what do
you want out of repl in terms of better MIME handling?
--Ken
___
Nmh-workers mailing list
N
>> So, I have some thoughts in this direction, but I'm wondering: what do
>> you want out of repl in terms of better MIME handling?
>
>All the "text" parts turned into UTF-8 and quoted would be a good start.
>I can then trim down in vi as normal.
Yeah, to me that would make things 100% better. Th
>The problem with that approach is that sometimes the text part just says
>``There is no text part, use an HTML capable mail reader''. I'm seeing
>more of them these days.
Yeah, I've seen those occasionally but I'm willing to put that problem
off for a little while.
--Ken
__
> I am writing this on a system that is still in
>FreeBSD8.x so everything still works but after upgrading a
>system to FreeBSD9.0, I got the following show-stopper the first
>time I replied to a message:
mha-mhedit isn't technically part of nmh, but the author of it is on
this list. But a
>*Please, no!* Conversion from any charset to utf-8 is possible, but
>conversion back, according to user preferences, is not. People
>start to use funny characters like non-breakable space and so on.
Unfortunately, we don't have unlimited development resources.
Here's my reading of the world:
-
>I assumed nmh would convert to UTF-8, I'd edit a UTF-8 draft, and that's
>what it would hand over to the MDA.
That works great if your locale is UTF-8 ... but what if it isn't? That's
where life gets complicated, and I think that means that it's just going
to suck for some people. Of course it
>For English-speaking countries UTF-8, in majority, means ASCII,
>they can see no difference. As an advantage they can use foreign
>names like Moebius in original, this makes message more readable.
>But I'm afraid they wouldn't be happy with message written in
>Russian, Chinese or Korean.
Well,
>Shouldn't you guys also be talking about pick in connection with
>messages containing Mime?
HOPEFULLY if I do things right, pick should Just Work.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-
>> - If we have to choose one, the only logical choice is Unicode (which in
>> practice means UTF-8; maybe UTF-16, but a trip through the format
>> code made me think that UTF-8 is probably the only real choice).
>
>One very reasonable option would be to use the current locale default.
>This is
>But doesn't the pick API need new primitives, such all messages containing a
>given mime type, all messages containing more than n mime types, etc? Or do
>things like -search and --component somehow make those easy?
Sigh. One thing at a time, okay? Yes, pick probably does need
some of those add
>What do you mean by "internal representation"? Conversion from
>any to utf-8, processing by the code and conversion back to the
>original charset is really internal, transparent for the user.
Well, for example ... when you call fmt_scan(), what should the character
set be? Just one example. Tha
>Couple of years ago emacs switch to "internal" coding in utf-8. I
>had to stop using emacs and mh-e.
See, this is what I'm missing - why, exactly? I assume the problem was not
just philsophical.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.
>Do I really have to bring in automake as well? Or is this just an
>oversight in generating the shipped configure.ac?
If you run autogen.sh, it will run aclocal with the right option which
should make it all work out.
(Although ... you will probably need automake either today or tomorrow :-/).
Greetings all,
As I've said/threatened before, I have been working on converting nmh over
to Automake. I'm pleased to announce that I believe the conversion is
complete, and I've just pushed that work to the master branch.
Some notes:
- We're not doing recursive make anymore; everything is buil
>Yep, I've just run into this (also on CentOS). No problem, I thought,
>I'll just bite the bullet and install the latest autoconf from source.
>But no, it seems autoconf itself requires autoconf 2.60 or later to
>build :-(
Did you try it directly from the revision control tree, or from the
distrib
>1) mhshow -form mhl.null should display Date, To, From and Subject
>
>2) allow for globs like ignores=X-* and ignores=List-*
Catching up on old messages ...
Can't you achieve this by simply removing the "extras" line from the
mhl format file? (Just checked ... yes, that makes it so everything n
>> Can't you achieve this by simply removing the "extras" line from the
>> mhl format file? (Just checked ... yes, that makes it so everything
>> not explicitly matched doesn't get displayed).
>
>I guess that doesn't help if you want odd unknown ones to be displayed
>but to skip known ones en mass
So this has bugged me for probably forever.
Putting aside the crappy MIME handling, one of my biggest annoyances when
doing repl on a message is that when lines are long, they get wrapped poorly.
Basically, right now if they exceed the column width they are broken at that
point. To me, this sucks
>As an aside, I use repl's -format, i.e. each line prefixed with `> '
>with no wrapping and so no issues, and then use vim's normal built-in
>formatting to handle getting the line length down once I've done by
>trimming of the quoted text to just what's pertinent.
So, what does your repl format fi
>My replgroupcomps is broadly similar to the system one. I think it's
>the -format that stops the wrapping; repl(1):
No, definitely not. I just tried that on a message with "long" lines and
it did the same crappy line wrapping. And I've been inside of that code
today and I can't see of a way t
Alright, so let me see if I can read the mood of the room ...
People aren't so crazy about adding more text formatting smarts to mhl;
that makes sense to me, I think whatever code I add wouldn't be as good
as something like fmt or par, and that's keeping with the toolset idea
of nmh.
So here's wh
I started looking back at the list of things I wanted to do that I
posted here in the beginning on December, and I realize now that
we're in pretty good shape on them! We have a new release out the
door, we've migrated to Automake and cleaned up our Autoconf setup
a lot, we are now packaged with M
>> One of the major wrinkles is ... well, m_getfld() is a complicated hot
>> mess. I know some of the people here have been inside of it; if they
>> wanted to impart some public knowledge here about it, I for one sure
>> would appreciate it.
>
>my thought is, fire photon torpedoes. m_getfld was th
>> - Given the above ... do people think there is value in rolling another
>> release soon-ish?
>
>Release early, release often.
Okay ... but are people going to try those releases out and give feedback?
Bill, I'm looking at you :-)
--Ken
___
Nmh-wor
>I'm more of the opinion that mhl *should* do some basic line wrapping,
>but with the option to instead invoke an external app that might be
>able to do a better job. I don't have a massively strong objection to
>not doing so, but it seems wrong to be shipping mhl in essentially a
>broken state. I
>i've just looked at m_getfld.c, for the first time since 1994 or so.
>this was good code in the pdp11 era.
>[...]
Wow. Okay, that was actually pretty damn useful; thanks for the
tutorial, history lesson, and brief primer on VAX assembly! I hope
it wasn't too painful for you! :-)
Okay, you've c
>Does par do anything "better" than doing "gqap" in Vim? I'm recollection,
>albeit from a few years ago, is that par inferior.
Hm, I just tried it on the paragraph above, and it seems to do
alright. Not sure how to easily judge whether or not it's "better"
than par, though. Of course, the line
>i expect that 'vim' cannot run as a filter the way 'par' or 'fmt' can, so the
>relevance of its feature level to MH's problem set is eluding me.
No disagreement here; I suspect Steve was really saying, "Hey, do we even
need to call an external format program?". My answer would be "yes",
because
In the "reducing the number of knobs and/or #ifdefs" vein ...
Right now POP support for inc is turned off by default. Thinking
about this, it makes no sense to me ... the amount of code is
relatively small, and we've run into a case recently where we had a
submitted patch that broke POP support b
>I still use mail(1) for sending one-line emails or in pipes. It's
>provided here by the heirloom-mailx package, derived from Berkeley Mail
>8.1 but brought up to date. A concise list of features,
>http://heirloom.sourceforge.net/mailx.html
Thanks for the pointer, Ralph. It's actually interesti
>More imporant (for me) is the possibility to send only file(s) as
>attachements.
>
>echo Enclosed | nail -a some.file some...@somewhere.net
>
>Similar functionality has mutt, switch -a. I can't do it via nmh.
That's actually not true; you can do that today with mhn directives.
Okay, not very fri
>On 1/31/2012 5:03 AM, Bill Wohler wrote:
>> Agreed. These feature-level ifdefs might have been useful in a day where
>> adding 2 kB to a library was horrid. Not so much today. I also agree
>> with Paul that if it pulls in an additional external library, the ifdef
>> is still appropriate.
>
>ok so
Greetings all,
I just committed support for external filtering inside of mhl. It only
works on the message body, but I still think it's useful (trust me, it
was too hard to make it work in the general case).
The man pages have more detail, but basically you want to put something
like:
formatpro
l/inboxsendKJwMrv: File exists
Thanks for checking! Yeah, turns out that had been broken for years.
The following patch should fix it. I am now mulling over whether
to release a 1.4.1 or a 1.5.
--Ken
commit 01943d78230ead5bcc568e8a87d3cdbaac1f5584
Author: Ken Hornstein
Date: Wed Jan 11 1
>> ... I am now mulling over whether to release a 1.4.1 or a 1.5. --Ken
>
>if we're going to do 1.5 then let's get all of the posix, ansi, and
>ifdef-removal work done and in.
We haven't done a branch for 1.5 yet, so anything we would do would be
from the tip of the master branch.
I've been using
>well then let's get some branches collapsed. afaik, there are
>portability and ifdef cleanups still out there. if we're doing a 1.5
>then anything other than an outright MH fork should be fair game. is
>there a list of branches and do we know how ready various of them are?
Well ...
% git branch
>so if i checked out the master, made a branch, and put some portability
>improvements on it, the timing is right?
Definitely!
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
>Done. The syntax is odd so I'll record it here:
>
> git push origin :posix_conversion
>
>I also deleted the fileproc_mhlproc_to_post branch, it was merged a
>while back.
One additional nit: if you want to delete those branches on your local clone
of the git tree you need to do
git pull
Alright, here are some things I've been thinking about in no particular
order:
- I think we have enough new stuff that a new release based on the tip
of master is worthwhile. Let's call it 1.5, since it doesn't feel
fresh enough to me to make it a 2.0. I'd rather invest my energy in
doing
>> I propose we have a new .mh_profile entry that is used as the default
>> From: when one isn't supplied in a draft. Objections?
>
>I would rather we use the existing components framework to do this.
>Growing a new option is just bloat, IMO. Thus my comments a few weeks
>back about having the in
>i think that we should not emit a From: without an @FQDN, or fail to
>emit a From:. if the components file did not give us a From: then we
>should autogenerate From: `whoami`@`hostname` and let the gods sort it
>out.
So that's what we _used_ to do. I kinda punted on that a bit. Turns out
that k
>On 2012-02-03, at 10:59 AM, Ken Hornstein wrote:
>
>> I thought about this ... but that would mean we ditch the installed
>> system components files completely, and it's not clear what we do for
>> existing users.
>
>I would use the system-side components as t
Alright let me see if I've captured the consensus:
- Make the "default" email address be (in decreasing precedence order)
- A knob in .mh_profile (Local-Mailbox ?)
- `whoami`@mts.localname
- `whoami`@`hostname`
- All drafts get run through mh-format
- All default component files now
>>- If there is a draft without a From that is fed to post, it will error
>
>erp? What sort from From is it going to require? I currently use
>
> From: me
No requirements other than it exists and is parsable by nmh (any
From: line that exists today has to be parsable by nmh). If you
just have t
>Isn't that what the (now poorly named) "Signature" mh_profile entry
>does? I used to use it for this purpose, anyway.
All that Signature does is serve as a replacement for the GCOS field
from /etc/passwd. mh-profile(5) specifically says to not put an address
in there. So we need something else.
>Would somebody be willing to tell me how to download the 1.4 sources?
In addition to what Paul said, if you go under the nmh web page on
savannah (https://savannah.nongnu.org/projects/nmh/) there is a tab
up top marked "Source code". You can get brief instructions on how to
use git, but if you d
>(for those new to git -- the links that ken pointed out don't point at
>physical tarballs -- when you click, a tarball is created on the fly,
>based on the tag that ken attached to that point in the git repo.)
One more followup :-)
It occurs to me that those auto-generated tarballs will require
So Lyndon pointed out to me in private email that on BSD systems we should
be using flock for locking. (Specifically, the mail spool on those systems
uses flock). But this made me realize that locking in nmh is a big mess.
I think we can divide locking into two categories - the mail spool, and
e
>On CentOS 5, I get the following compile time errors:
>reference to `tgetnum' termsbr.c:(.text+0x132): undefined
>[...]
>reference to `tgetnum' termsbr.o: In function `SOprintf':
>termsbr.c:(.text+0x1be): undefined reference to `tputs'
>termsbr.c:(.text+0x1f9): unde
So let me summarize:
- We should definitely fail in configure if we don't find a curses library,
since that's required to build nmh.
- From a distribution tarball you don't need lex/flex; what happened to
you was the old "make distclean" target removed dtimep.c (and as David
Levine pointed
>second, message numbers are currently file names. if we succeed in
>abstracting things correctly, they might refer to imap objects some day.
>in which case i suppose that mhpath will emit imap: url's?
I've often thought that in hopefully-not-too-distant future when we had
IMAP support, something
>In the IMAP case, you don't want to download the entire message just to
>satisfy an mhpath request. The value in IMAP is its ability to treat
>MIME sections as separate objects. By sucking down entire messages, all
>you've done is downgrade IMAP to POP.
I understand where you're coming from, but
>No, you need to download text parts. It would be pointless to download
>the 15 multi-MB TIFF attachments as well.
Huh, I guess I was thinking that you had to download the whole message
body, but I guess I shouldn't go up against an IMAP expert like you :-)
I took a closer look at RFC 3501 and I
>It's not that hopeless. If the IMAP server supports the METADATA
>extension (and most modern servers do), we can almost fully support
>anno.
So ... looking at RFC 5464 ... for anno you would do something like:
SETMETADATA INBOX (/private/nmh/${imap-uid}-anno "Replied: Mon, 06 Feb 2012")
As I u
Greetings all,
I've been (slowly) working on sorting out the whole From: mess that
was discussed earlier, and of course like many things in nmh there are
a ton of assumptions that makes this a lot harder than it needs to be.
But I digress ...
I came across the code in post that handles the masque
101 - 200 of 2882 matches
Mail list logo
