Resurrecting an old topic, Email Address Internationalization (EAI).
The original message is at
http://lists.nongnu.org/archive/html/nmh-workers/2015-08/msg0.html
It doesn't mention RFC 6531, SMTP Extension for Internationalized
Email, which is what this message is mostly about.
Ken wrote:
>
Ken wrote:
> I've been poking around and I see that there is something that MIGHT
> be worthwhile to look at: something called "trust on first use" (TOFU)
Sounds good to me, I'd use it.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https:/
Laura wrote:
> Whatever we come up with, I will need a setting for 'default utf'
> to handle my little corner of the world. I don't want to type send -eai
> for practically every piece of mail I create or reply to. :)
Oh, this is just about EAI and that's a much, much smaller corner of
the world
Laura wrote:
> I think this may be an advantage of living in a part of the world
> where ASCII is too small.
I don't know much about utf-7, but a quick look around shows that it
reduces the need for base64 or quoted-printable encoding.
> mhshow-show-text/plain: \
> iconv -f "$(charset=$(echo %a
Ralph wrote:
> I meant to mention a barmy idea about dropping a "welcome" email on the
> unsuspecting.
Or add the welcome to the output of install-mh(1)? Its output is
brief enough now that it shouldn't be lost. Question is whether new
users use install-mh, though if they don't, they probably d
Laura wrote:
> I interpreted this to mean local sysadmins at the site where you are
> running nmh, i.e. somebody at Chalmers University, not you people. If
> you want to hear from people, I think you need to be a whole lot more
> welcoming.
How about this, in nmh(7) and the output from install-m
Paul wrote:
> any reason we couldn't in principle have a separate git tree on
> savannah just for "compiled" man pages, and other docs?
Is there really a need?
And a separate tree is more likely to get out of sync.
David
___
Nmh-workers mailing list
Paul wrote:
> perhaps replyfilter should move to libexec.
The problem is the replyfilter uses perl and Ken doesn't want to add
that as a dependency. (I agree.)
There will be a native solution in 1.7:
repl -filter mhl.replywithoutbody -convertargs text/html '' -convertargs
text/plain ''
T
Laura wrote:
> In a message of Sun, 25 Sep 2016 12:57:19 -0400, David Levine writes:
>
> >How about this, in nmh(7) and the output from install-mh(1):
>
> This looks good to me.
Thanks. I added it (along with where to subscribe to the mailing
list) to the nmh(7) man page
ly could the Fedora
> >> package owner to roll an EPEL version?
> >
> >Yeah. Try filing a bugzilla request for that (against the existing
> >nmh package, I think).
>
> Looks like David Levine is the package owner (along with Josh Bressers).
> So maybe that
William wrote:
> I'd prefer a seen sequence to an unseen sequence as this would let
> an MDA deliver directly into an nmh folder without needing to update
> the .mh_sequences file.
So would rcvstore -nounseen, can you use that?
> Possibly implemented by checking the specified unseen sequence for
Oliver wrote:
> Could we perhaps include a configure test
Easy, just add getline to the AC_CHECK_FUNCS in configure.ac.
> and a fallback implementation such as the one below (it is a
> public domain implementation tweaked to use mh_xmalloc etc)?
If we include that implementation, I think we sho
Valdis wrote:
> It's not in the EPEL repos either (which are basically extras
> from Fedora built for Red Hat).
For EL6, the build needs to use autoconf268 instead of
autoconf. And it needs automake 1.12, but it looks like
automake 1.11 is installed, so that might be a show stopper.
And worse o
I wrote:
> For EL6, the build needs to use autoconf268 instead of
> autoconf. And it needs automake 1.12, but it looks like
> automake 1.11 is installed, so that might be a show stopper.
>
> And worse on EL5: I don't see any autoconf or automake.
I requested an EPEL7 branch. It looks like it h
Tom wrote:
> Normal expectation is that builds should be done from a released tarball
> if the upstream publishes such.
The spec had autoreconf -force. I removed that and the auto* dependencies,
and now builds succeed. I'll submit.
Thanks!
David
__
Ken wrote:
> The exact issue is that some MUAs will use RFC 2047 encoding
> for a filename that contains 8-bit characters when creating a
> Content-Disposition field.
> I am torn as to what to do here. It feels somehow wrong to support this
> for decode natively, but I'm not completely convinced
I added a welcome message when nmh detects that its version
changed. You'll you see it the first time after checking out
the welcome branch (and 1.7, assuming we want to keep this).
It doesn't happen if stdin or stdout isn't connect to a terminal,
or for any of these commands:
mhbuild, mhfix
Paul wrote:
> is there a "press enter to continue?" prompt? if not, many commands
> which bring up an editor will tromp on that text before it can be
> read.
Oh, good idea, I'll add it.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http
Ralph wrote:
> So both have to be to a TTY. Perhaps stderr, where the welcome appears,
> should be too? Otherwise a `2>/dev/null' in someone's script might
> throw it away.
Agreed, I'll add stderr. Thanks.
David
___
Nmh-workers mailing list
Nmh-wor
Oliver wrote:
> I like to have a different current folder in different terminals so in
> my .zshrc, I do:
> export MHCONTEXT=/tmp/context.$$
> I've also got aliases which point it to /dev/null to prevent folder
> changes, e.g:
> alias new='MHCONTEXT=/dev/null flist +inbox +nmh-workers +
>
Eric wrote:
> but it crashes after a few messages with "inc: TLS peer aborted
> connection".
I see the same behavior. It looks like it's repeatable, always
happens in the same place.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://l
Ken wrote:
> > [Ralph:]
> >Would it be more useful to demand From be a single header in the draft,
> >though still allow that one header to have multiple addresses? That
> >would catch the accidental sending of a multiple-From draft due to
> >editing woes whilst still allowing multiple From addre
I wrote:
> Ken wrote:
>
> > The exact issue is that some MUAs will use RFC 2047 encoding
> > for a filename that contains 8-bit characters when creating a
> > Content-Disposition field.
>
> > I am torn as to what to do here. It feels somehow wrong to support this
> > for decode natively, but I'm
Ken wrote:
> >[Earl:]
> >I do not recommend blanket 2047 decoding for parameter data. Just limit it
> >to parameters associated with a filename.
>
> I find this argument convicing; thoughts from others?
That's what I implemented in mhfixmsg: just Content-Type name and
Content-Disposition filena
I almost hate to bring this up, but . . . mhstore already asks users
(if isatty). We could do something like:
the filename of =?...?= is encoded, save as unencoded [...] instead? [y/n]
And define what to do if the response is no.
If not a tty, we're back to the question. Safer to fail, fri
As Ralph noted a while back[1], SMTP has an 8BITMIME extension.
nmh currently doesn't support it, except for the recently added
EAI (SMTPUTF8, RFC 6531) corner case. I'm thinking about adding
full support for it.
One approach would be:
1) In post, look for a Content-Transfer-Encoding header. It
Ralph wrote:
> Hi David,
>
> >If the server doesn't support 8BITMIME, fail with a message to user
> >that they need to encode the message for 7-bit transport. That
> >would be a change from current nmh behavior.
>
> Current behaviour being it spots top-bit-set bytes and QPs or base64s
Earl wrote:
> For any file nmh creates based on email parameter input, it should run it
> through a sanitizer to remove any characters deemed invalid and remove any
> pathname components.
For security reasons, this filename will be ignored if it begins
with the character '/', '.', '|', or
Earl wrote:
> Decode.
I'm leaning that way, too.
> How often are real files with "=?...?=" in their name them encountered?
Often enough for some.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh
Lyndon wrote:
> > On Oct 6, 2016, at 5:20 AM, David Levine wrote:
> >
> > The /etc/passwd or relative pathanme will be ignored, and a name of
> > the form message#.part#.subtype will be used instead (assuming no
> > profile override).
>
> I think this is ve
Lyndon wrote:
> > On Oct 6, 2016, at 8:11 PM, David Levine wrote:
> >
> > But I wouldn't consider the likely result with filename=/foo/bar/README
> > to be safest.
>
> Why not? If there is no "README" file, create it. If there is, prompt for a
>
Ralph wrote:
> Regarding the
>
> [ part 2 - application/postscript - foo.ps ]
>
> that appears when viewing an email, has any consideration been given to
> looking up a `summary' command for the MIME type/subtype, falling back
> to type, in the same vein as mhshow-show-* profile entries?
I ge
Ralph wrote:
> I get MIME type and Content-Description, if there is one.
> Is that `4.4KB (suppressed)' part of the C-D?
No, but I see what it is. I'm actually using master, not 1.6, and
DEFAULT_MARKER in mhshowsbr.c now has %(kilo(size).
> Mm, just a bit tedious to have to tack onto a `show' f
Ralph wrote:
> Hi Oliver,
>
> > A number of tests are failing on Solaris. This seems to mostly consist
> > of:
> > id: illegal option -- u
> > Usage: id [-ap] [user]
> > FAIL: test/mhmail/test-mhmail
>
> http://git.savannah.gnu.org/cgit/nmh.git/tree/test/post/test-post-common.sh#n12
> sugges
Ken wrote:
> [Anders:]
> >Trying to send a single message interactively...what's the mts.conf
> >settings required? I tried server=smtp.gmail.com and strace suggests that
> >it figures out to use port 587 itself (triggerd by the -sasl I guess),
nmh (post(1) now defaults to using the submission po
Norm wrote:
> But what I don't understand is why isn't it? In fact, why isn't that
> an option to forw, or even its default?
I'm not sure what "it" is. Do you want to include attachments from
more than one message? Do you want to always include all attachments
from those one or more messages?
Also, you'll need to use mhlogin before using xoauth2. See
the mhlogin(1) man page for instructions and example with
Gmail.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Laura wrote:
> But I get them in the order they arrived. I want them in the order they
> were sent, which can be a whole lot different, before I read them.
>
> I use my own filter for that. Be nice if nmh did that natively. as part
> of folder?
Sounds like a job for sortm(1). It defaults to u
Oliver wrote:
> Another issue is that tests using require_locale look for locales
> in lowercase, e.g. en_US.utf8. On Solaris plus various *BSD systems,
> these are output in uppercase form, e.g. en_US.UTF-8.
Fixed.
I haven't looked at the getline() replacement. Are you going to
do that? Your
Ralph wrote:
> +1. The `Forward' header is grabbing another one for nmh's use, in
> addition to the existing `Attach'. Should we be using `Nmh-Forward' if
> the user isn't likely to have the hassle of typing them most of the
> time?
Absolutely. The existing code allows either Nmh-Attach or Att
Ken wrote:
> > [Ralph:]
> >Because the sooner we create the prefix, the sooner future new headers
> >can fall under it. Ken says we discussed this over `Attach'. Here we
> >are for `Forward'. Next year it will be another one?
> My recollection is that it actually came up originally for
> Envel
Paul F. wrote:
> lyndon wrote:
> >
> > This means, moving forward, we only generate nmh-* headers, while
> > continuing to accept the old ones.
Yup.
> > This is particularly important now that "forw -mime" is becoming
> > the default; these headers *will* escape now.
>
> why? how? it see
Paul F. wrote:
> david wrote:
> > Note that post scrubs Bcc, Dcc, etc. But not Nmh-Attach or Attach.
>
> why not?
Actually, I was mistaken: it does filter out all header lines that start with
"Nmh-".
As to why it doesn't scrub Attach: because no one implemented that.
> > Also, nmh (whatno
Ralph wrote:
> I've written a getline(3) from scratch based on
> https://manned.org/getdelim.3p and am happy for it to have whatever
> licence nmh needs. I've assumed POSIX, e.g. stdbool.h, SSIZE_MAX, etc.,
> so it may need some conditional preprocessor bits for portability to
> older systems.
C
Oliver wrote:
> For the autoconf/automake stuff to replace getline, the following
> patch seems to work. Should AC_REPLACE_FUNCS perhaps be earlier or
> later in configure.ac?
>
> The final change on configure.ac is to cope with cc -V output having
> slightly changed in the most recent version of
Norm wrote:
> But sometimes I forget to otherwise address the message. But
> then send will just go ahead and send the message, instead of
> balking, as it would if I used fcc instead of cc.
>
> Is there a workaround that problem?
I always "w" at the What Now? prompt before sending.
David
_
Ralph wrote:
> Hi Oliver,
>
> > Just two failures left:
> > usage: script [ -a ] [ typescript ]
> ...
> > This is a new check with the welcome message stuff. Judging from
> > online man pages for script, this will have problems on other systems
> > too. OpenBSD for example, only seems to have
Ken wrote:
KH> I guess this illustrates one problem with open-source projects; who makes
KH> the decisions when people disagree? It's not that people who want
KH> an Nmh- prefix are being unreasonable; I mean, I understand all of their
KH> arguments; I just think my arguments are more compelling.
Paul F wrote:
> not if i'm already in my editor, it's not. and if i wait until leaving
> the editor, i'll likely forget the attachment. so i sometimes use an
> editor macro to create the Attach: header, and sometimes i type it by
> hand.
Fair enough. Though the editor macro could just as easil
Paul F wrote:
> sure, but that's a bug.
I'm not sure about that. What if the user has a legitimate reason
to use a such a header? And we can't predict all such pseudoheader
names out into the future. nmh should squat on the Nmh- namespace
to severely minimize this issue.
David
__
Ken wrote:
> I can boil it down to this: these headers may leak out, if there are bugs
> or unusual behavior. But I have realized ... I don't care.
I do care. "Be conservative in what you do"
> Thinking about it more, we already leak some "internal" headers out.
Water under the bridge. Let's
Paul F wrote:
> but there's no solution, to this, right? we can't control typos, whether
> there's an Nmh- prefix on the header or not. and we're not going to change
> Fcc/Dcc/Bcc in any case. so isn't this is a moot point?
We can't eliminate the effects of arbitrary typos, of course, but we c
Ken wrote:
> - Traceability - I mean, why is this an issue? Who would really care?
I count four people who have responded that they do. I might have miscounted,
but obviously some do care.
> - Polluting the namespace - I mean, also ... really, is this a thing we
> should have to worry about?
Jón wrote:
> This morning I got a notification from the package manager that
> a new version of nmh was available. This was a nice surprise as
> hitherto I had built my own rpms for nmh (and was rather behind
> the times). So now upgraded to 1.6
>
> I didn’t see any mention on here that this was g
Ken wrote:
> Also ... if we are having post(8) scrub out headers with an Nmh- prefix,
> we could also have it scrub out any header, like Attach:,
No, we can't. See previous messages from Ralph, kre, and me on that.
David
___
Nmh-workers mailing list
Ken wrote:
> So if traceability is the major concern, would a User-Agent header
> address everyone's issues?
No, because:
Nmh-Attach: foo
User-Agent: nmh-1.7
is more informative than:
Attach: foo
User-Agent: nmh-1.7
And, "This means, moving forward, we only generate nmh-* head
Ralph wrote:
> > > I think the test is mhparam(1)'s checking for a TTY on FDs 0, 1, and
> > > 2. OpenBSD's man page says $SHELL is used. Perhaps the test can
> > > make use of this.
> > >
> > > $ cat >cmd
> > > #! /bin/sh
> > >
> > > mhparam path
> > > $ chmod +x cmd
> > > $
Norm wrote:
> Turns out it is documented, though not in a very straightforward place.
> man mh_profile, under postproc.
I'm in documentation mode, so if you have a suggestion on where to add
a link to that postproc entry, please let me know. Where is the first
place that you looked? post(8), ma
Ralph wrote:
> 1.6's mhshow(1) says
Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38
have fixed this?
> I took a look at mhshowsbr.c's convert_charset() and I think it's
> failing to handle an EINVAL return.
That commit adds handling of EINVAL and EISLEQ, relevant portion of
the diff
Ralph wrote:
> > 1.6's mhshow(1) says
> >
> > mhshow: unable to convert character set to gb2312, continuing...
>
> I meant to draw attention to that. It was converting *from* gb2312 (to
> UTF-8).
Fixed, thanks.
David
___
Nmh-workers mailing list
Norm wrote:
> But I wonder how much additional clarification is wise. Perhaps nmh
> documentation is reaching, or has reached, the law of diminishing returns. The
> more man pages that are added and the longer man pages become, the harder it
> will be to find something, and the less likely it woul
Ralph wrote:
> Hi David,
>
> > Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38 have fixed
> > this?
>
> Yes, indeed.
Great! We'll get you to the bleeding edge yet.
> IOW, it seeks to 4Ki and reads 4Ki - 1 so it's left in the right place
> to read the one byte, that we already have,
Ralph wrote:
> Hi David,
>
> :-) Through a cunning bit of social engineering the other day,
I don't want to know :-)
> I did apparently gain access to nmh's git repository. Is there
> anything that documents conventions in using it for the project,
> e.g. whether to check in directly on master
Ralph wrote:
> Thanks, that helped quite a bit. I've pushed a trivial fix to master.
> If I've done anything wrong, e.g. not configured my ID properly, then
> let me know.
Looks fine.
One thing that we should add to README.developers, the buildbot results
are available at http://orthanc.ca:8010
Oliver wrote:
> I prefer that we don't have Nmh- prefixes on our headers. Apart
> from it seeming ugly
Don't look at them :-) I am serious. These directives are for
internal nmh use, not to please the eye unless that can be done with
no drawbacks. Note the two distinct purposes described earli
Ralph wrote:
> Hi Norm,
>
> > While developing and debugging a postproc, I want to use nmh to send
> > mail without using the postproc that I'm debugging, but to use it
> > sometimes when I do a send.
>
> Keep toggling the name of the postproc entry?
>
> sed -i '/^x*postproc:/!n; s/^x/y/; s/^p
Paul wrote:
> david wrote:
> they're no more "internal" than "Fcc". so pleasing the eye, is,
> actually, not unimportant.
If you want to talk about typing them in, I could understand. Pleasing
the eye, I just don't get it. Nmh-Attach doesn't look that much different
to me than Attach. (And i
Ralph wrote:
> Rather that re-tread worn ground, how about a considered reply to my
> suggestion that all headers be known to nmh and the user having to add
> to that list,
Is "user having to add to that list" in your original proposal?
I'm missing it. Is it a profile entry to allow the user to
Ralph wrote:
> I'm moving all the headers into nmh's domain, the ones it cares about in
> drafts, anyway. This is only talking about draft processing. So
> `Received' isn't in the set. In effect, all draft headers become nmh
> directives, none of them are wire headers any more. Directive `To'
Ralph wrote:
> I've noticed things like test/fakepop only get built on a
> `make check' because that needs to use them. OTOH, it would be nice to
> see compilation succeeds along with everything else in the `all' target.
Maybe add a phony target that would build the test programs?
Then either sp
Ralph wrote:
> Can't you all just have a checkout of the last git with MH
> to look at for reference? :-)
I'd prefer putting it into a separate repo. But OK, if we
tag it and promise not to remove the tag. I don't feel
strongly about it.
David
___
Ralph wrote:
> Whatever would be most useful for you that refer to it.
Doesn't matter, I'll put it in a separate sandbox. Branch
sounds like a good idea, so we add to it.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu
Ken wrote:
> >[Tom wrote:]
> >I thought Laura's suggestion was to be able to put something like
> >
> >locale: en_GB.utf8
> >
> >into ~/.mh_profile, which seems eminently sensible to me.
>
> Sigh. I won't object if someone does this work ... but it's not something
> I want to tackle, for the afor
Lyndon wrote:
> What about an $NMH_LANG environment variable that the runtime
> could look for *very* early on, and use to seed $LANG.
I'm not a fan of environment variables when there's an alternative.
The profile seems like a good home.
> Seems like minimal impact to the rest of the code that'
Lyndon wrote:
> > On Oct 17, 2016, at 6:13 PM, David Levine wrote:
> >
> > I'm not a fan of environment variables when there's an alternative.
> > The profile seems like a good home.
>
> $NMH_LANG -> <.mh_profile> -> locale() seems like
Laura wrote:
> I don't know about Tom, but my problem isn't that I want to send valid
> US-ASCII emails, but that I _never_ want to send valid us-ascii emails.
> And the last thing I want to happen is for nmh to not be able to
> tell what I want, stick in us-ascii (because the thing needs a
> con
Ken wrote:
> I noticed that test/install-mh/test-version-check is hanging for me
> on MacOS X. Specifically, the "script" command on MacOS X seems to be
> the problem; for reasons I don't understand quite yet when "script" is
> run the input is set to /dev/null, and it turns out when THAT happens
Ralph wrote:
> I'm not sure why script(1) is run in the background and then immediately
> wait'd for; is it to just get byte or few of input without wait-ing? echo | ...
The test originally did that, but 1) the man page on Linux cautions against
it, as shown by the excerpts that Ken posted, an
Ralph wrote:
> OK, I'll add a check-programs target to Makefile.am then so I can do
> `make all check-programs' without running all the tests.
Thanks.
> I've been going for lots of little commits to help bisect.
Thanks!
> Poking around etc/gen-ctype-checked.c and the related code, I've found
>
Laura wrote:
> And, of course, I do use attach at the What Now? prompt.
So, another approach to get what you want (8-bit message even if
it contains no 8-bit characters) would be to do all this:
1) Add support for locale profile component to nmh.
2) Use latest nmh (HEAD of master) or upcoming nm
Lyndon wrote:
> I.e., the standard (MH-modified) UNIX model is:
>
> 1) command line (-locale)
> 2) mh-command-specific profile entry (.mh-profile)
> 3) environment ($NMH_LANG)
> 4) profile default override (.mh-profile)
> 5) OS environment default (locale())
>
> It's arguable about the ordering of
Ralph wrote:
> That's just been updated to not be generated and use the single identity
> array I mentioned.
Cool.
As far as getting automake to create the etc dir, I think there should be
a way to do it by moving mhn.defaults to a variable that automake will
recognize.
David
_
Paul F wrote:
> (in the interests of sampling all the dogfood, i guess :-)
Have you tried the following?
repl -filter mhl.replywithoutbody -convertargs text/html '' -convertargs
text/plain '' "$@"
That mhl file includes the attribution line. mhn.defaults
uses sed to insert the leading '> '.
I committed the locale profile component support.
Ken wrote:
> Turning this around ... all we really care about is LC_CTYPE.
Historically, MH and nmh have set LC_ALL. Should we just set
LC_CTYPE instead?
David
___
Nmh-workers mailing list
Nmh-worker
Ken wrote:
> You mean setlocale(LC_ALL, "")? Which really means "Just take everything
> from the environment", right?
Right. More accurately, set everything based on the first of LC_ALL,
LC_CTYPE (that's all we care about), and LANG that is set (though
implementation dependent, that seems commo
Lyndon wrote:
> The overhead of $NMH_LANG isn't even measurable, and the code path is trivial.
Yes. But, I just don't want to burden the maintainers, and add
roughage to the documentation and test suite, for a feature that
I don't think will be used. It's easy to add later if we need,
hard to t
Lyndon wrote:
> I'll add it when if/when I need it.
How bout I change the LC_ALL in the setlocale() to
LC_CTYPE? Then you can override with $LC_ALL.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/n
Ralph wrote:
> I've since overridden configure's CFLAGS to add `-pedantic
> -ansi', but I wonder if m4/cppflags.m4 should attempt these
> and add them if they work?
We used to do this, but I removed them in commit 987b10b3. My
thinking was that CFLAGS is up to the user. I still think that's
the
Tom wrote:
> David Levine writes:
> > Ralph wrote:
> >> I've since overridden configure's CFLAGS to add `-pedantic
> >> -ansi', but I wonder if m4/cppflags.m4 should attempt these
> >> and add them if they work?
>
> > We used to do t
Norm wrote:
> The send man page says "Most of the features attributed to send are actually
> performed by post.". That leaves me guessing as to the exact division of
> responsibility between send and post.
>
> I'm guessing, but am not certain, that the answer is in the next paragraph
> about mhbui
I wrote:
> Ralph wrote:
> > Minimal effort by those buildman, giving them a script to run.
>
> build_nmh, with a few other additions (curl or wget, showbuildenv)?
This now works:
wget http://git.savannah.gnu.org/cgit/nmh.git/plain/docs/contrib/build_nmh &&
sh build_nmh
Good enough? I didn'
Ralph wrote:
> Hi David,
>
> Worked well on a machine where I hadn't built it before, but was likely
> to have some of the optional development packages installed.
Yeah, the script doesn't check those dependencies in advance. The build
doesn't take very long on modern machines so I think that's
Ken wrote:
> I dunno, I think we'd need to think carefully if a particular use of
> strncpy() really warrants an abort vs a truncate. I mean, just crapping
> out on a really long line that other MUAs handle just fine seems rather
> unfriendly to me. What do others think?
I'm not a fan of abort,
Ralph wrote:
> I found the build on Mac OS X failed. build_nmh prompted `[n]' for TLS,
> which I accepted with Enter. That stopped --with-tls getting to
> ./configure; good. But configure defaults to yes, I think,
Yes, it did. I just committed a change to do this:
By default (with_tls='
Ralph wrote:
> Returning to that Mac OS X box to try it, I again went with the
> defaults.
>
> $ sh build_nmh
> Install prefix [/usr/local/nmh]:
> Locking type (dot|fcntl|flock|lockf) [determined by configure]:
> MTS (smtp|sendmail/smtp|sendmail/pipe) [smtp]:
> SMTP server(s
heymanj writes:
> I know all are giddy about the release of nmh 1.2 (will be compiling
> it this weekend), but I am curious as to how to resolve the following
> situation:
>
> On my office workstation, I use a different logon id than my email
> address (as given to me by the corporation I work for
I wrote:
> heymanj writes:
>
> > I know all are giddy about the release of nmh 1.2 (will be compiling
> > it this weekend), but I am curious as to how to resolve the following
> > situation:
> >
> > On my office workstation, I use a different logon id than my email
> > address (as given to me by
Hi,
I have been manually editing drafts to remove Content-ID
headers from outgoing MIME messages. The default
configuration of Microsoft Outlook, Build 10.0.3416, in
particular, doesn't see attachments in incoming messages if
there are Content-ID headers. (There are a few old postings
to comp.ma
> > I have been manually editing drafts to remove Content-ID
> > headers from outgoing MIME messages. The default
> > configuration of Microsoft Outlook, Build 10.0.3416, in
> > particular, doesn't see attachments in incoming messages if
> > there are Content-ID headers. (There are a few old post
> > > Can you perhaps define the sendproc profile entry to be a filter that
> > > forwards options and its output to send?
> >
> > That could work. It's easy to filter out all Content-ID:
> > lines. But if I wanted to keep forwarded messages perfectly
> > intact, it's not as simple. It usually
901 - 1000 of 1611 matches
Mail list logo
