I believe that IMAP support should be done mapping the files in the
mail server on a local in-memory filesystem as MFS, tmpfs, kernfs or
procfs do.
I disagree completely. The biggest appeal of MH, to me, is that it is a
natural offline IMAP client. If you restrict yourself to a temporary
On Feb 1, 2006, at 7:22 PM, David Levine wrote:
The almost part is that mhbuild currently creates
Content-Description instead of Content-Disposition. I
hijacked the Content-Description information and used it to
form the Content-Disposition header (with or without
-attach). (Is that a good
On May 24, 2006, at 7:59 PM, Jeffrey C Honig wrote:
1) If we start requiring regex, we need to fix configure. Will this
limit systems nmh can run on? Do we support systems that do not
have
POSIX regex?
Shoot configure and write to POSIX. There's nothing MH needs that
cannot be
A few comments from the peanut gallery ...
1) Any attempt at a portable programmatic method of dealing with
scratch files is doomed from the outset.
2) Hardwiring ~/Mail is as bad as wiring /tmp. Worse, in fact. The
purpose of /tmp is to host a portion of the file system that's *fast*.
On 2008-May-6, at 07:00 , [EMAIL PROTECTED] wrote:
With more and more ISPs blocking outbound 25, should we add code to
try to
use port 587 (submission) first, and fallback to 25?
Amen, and only with support for non-plaintext authentication
mechanisms. (CRAM|DIGEST)-MD5 cover the current
The book, Rand and the Information Evolution A History in Essays and
Vignettes by Willis H Ware, Rand Corporation 2008, contains about 10 pages
of MH history.
Sorry if this is a dupe, but I don't recall anyone mentioning that you can
download a PDF of this document from RAND:
Why? nmh doesn't need any new features, and the code is stable and
portable.
The best indicator that a chunk of code is mature is when it hasn't been
touched for five years. It ain't broke, so leave it alone.
--lyndon
___
Nmh-workers mailing list
know about you, but when I go to look at a software package and I see
the last new release was 5 years ago, my first thought isn't, Oh, it's
perfect! That's why they stopped developing it!; it's Oh, I guess
that project is dead.
I know. It's referred to as Slashdot syndrome.
On an daily
i know there have been a couple of fuse attempts at imap
integration -- i don't recall how far they've gotten. if it
weren't for possibly already having been done, i'd think that
would be an almost ideal summer-of-code project, since it would
be a somewhat stand-alone project, and something with
Lyndon said that nmh does not need someone like me to work on it.
Well, he's just ONE guy.
Ya, but I'll still take you all on!!! :-)
--lyndon
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Is a single threaded IMAP *CLIENT* really as complex as the server side?
No. It's about ten times *more* complex than the server side.
Most so-called IMAP clients are really POP clients that know how to switch
mailboxes.
--lyndon
___
Nmh-workers
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 support for years. The version shipped with your OS
might not
The utmp changes need to be guarded with '#if __FreeBSD_version =
90'. Otherwise this won't compile on 8.x or earlier.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
On 10-10-05 2:14 PM, valdis.kletni...@vt.edu wrote:
What should the code do on systems that have both utmp.h and utmpx.h?
utmpx is the new POSIX flavour, so I'd defer to it over utmp in that case.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
While I'm not particularly in love with autoconf or automake, my response
to people who say that they hate autoconf is: what do you propose we use
instead?
The POSIX standard. Everything MH needs in the way of APIs is provided
by POSIX. By coding to POSIX we eliminate the need for autoconf
590610/29 X XXX Re: Coming down your way soonThanks. I am
doin
5907+ 10/29 XXX X Election editorial
cartoons--Apple-Mail-19-856
.1 text/html I decided to stick to just one topic, since
the
.1.2 image/gif JGPfwdtoon.gif
On 10-11-03 11:27 AM, markus schnalke wrote:
Have you had a look into m_getfld.c?
Yes :-(
Doesn't seem as if the code was so easy to write the first time. It
probably will not be the second time.
It wasn't easy because it was all about micro-optimizations that reached
into dark places that
On 10-11-03 11:45 AM, Jon Steinhart wrote:
So let's figure out what's
really important. To me, that's Linux.
You are a lonely voice in a large crowd.
I have seven servers at home. None of them run Linux. I currently run
nmh on multiple major releases of FreeBSD, Solaris, and OpenBSD. In
I currently run
nmh on multiple major releases of FreeBSD, Solaris, and OpenBSD.
I forgot to include MacOS in there as well.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
On 10-11-04 11:44 AM, Mike O'Dell wrote:
i strongly suggest that KPOP not be deprecated unless you can prove
there are no sites using Kerberized POP.
You are still running Kerberos IV? Really?
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
On 10-11-04 2:56 PM, Chad Brown wrote:
I wouldn't be surprised if there are old MS installations still using krb4, but
I doubt that there are many that care about nmh.
Active Directory has been Kerb 5 all the way (although it was a
typically bastardized variant in its younger years.)
On 10-11-05 6:03 AM, Peter Maydell wrote:
Yes, please start with the CVS head.
Could someone please lay down a PRE_POSIX_CONVERSION tag that I can use
as a reference point for the patches?
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
On 10-12-01 8:21 PM, Ken Hornstein wrote:
I agree that was true maybe 20-30 years ago, but I am wondering:
What does Marshall Rose or John Romine use as an email client today?
Maybe they still use mh or nmh, but it sure wouldn't surprise me
if they don't (if we've lost Jerry Peek, then the game
On 10-12-07 3:48 PM, Jon Steinhart wrote:
This is the first that anybody has spoken
up about this as far as I'm aware, so I was trying to protect backward
compatibility.
A lot of MTAs just accept the stuff, even though it violates the
standards. The assumption was 'just treat it as 8859-1'.
i can also imagine storing the full rfc822 header object in this index so
that scan and many forms of pick can operate at the speed of modern
hardware. (stat()'ing ten thousand files in a directory has not gotten
faster over the years, whereas dbm_read()'ing 1 elements has gotten
really
I've seen this idea several times, and I always have the same question - how
would we deal with index/cache synchronization? One of the reasons I'm still
using MH/exmh is because the one message per file paradigm means that you can
do interesting things with regular Unix commands - except if you
2. Can IMAP unique IDs and such be stored as X-Header stuff?
Not reliably. The UID of a message is only meaningful within the context
of a folders UIDVALIDITY, and that can change behind MH's back. And
really, these are message store properties, not attributes of the messages
themselves.
Having repl default to flowed text would be a cheap way to accomplish
this. I'm not sure building in word processing capabilities is the
way to go.
Most systems still provide fmt(1), which was written specifically to
address this very issue.
--lyndon
On 2011-02-08, at 7:02, Ken
The only change in mts.conf is:
servers: smtp.tsoft.com
SMTP requires a fully qualified recipient address. You need to send to
user@local.domain instead of user, or change your nmh config to submit
mail by piping to sendmail (or whatever your MTA is).
--lyndon
I'd be up for doing this, but with one huge caveat: only if we throw
out all of the current Makefiles and use Automake instead. Given Automake's
current support for subdirectories, we could ditch the use of recursive
make, which in my mind is a pretty big win.
[ Sorry to be late to the party
On 2011-12-12, at 2:03 AM, Ken Hornstein wrote:
Yeah, I think we're all on the same page here. I'm all in favor of reducing
our #ifdef mess.
I'm on the road for the next week and a bit, but as soon as I get back I'll
push my POSIX work onto the working branch I created. It's not complete
I still have a couple of days work to do on the posix branch. I should be able
to get some time in on it this week.___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
On 2011-12-24, at 13:42 PM, valdis.kletni...@vt.edu wrote:
Just be glad they didn't use the CVS model of branches. :)
I LIKE the CVS model of branches!
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Do any of the git gurus know if it's possible to have the commit email
notifications include the branch name for non-master commits? Some of the
changes I will be making on the posix branch are going to make people totally
spazz out if they think these changes are going on the head!
--lyndon
Okay, smack me. The branch is there plain as day. I think I need to take a
few days off :-P
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
On 2011-12-24, at 15:18 PM, valdis.kletni...@vt.edu wrote:
CVS does branches just fine. It's merges that totally blow.
I dunno. When I have to deal with maintaining a local version of a 3rd-party
package, I still find CVS' vendor branch style of doing things very easy to
use. It might not
Will replacing vfork() with fork() seriously impact nmh performance on any
current UNIX variants? (How many VAX users do we still have?)
--lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
On 2011-12-26, at 10:13 AM, Paul Vixie wrote:
the time we spend discussing these things and working on separate
branches and then carefully merging those branches in, comes out of our
development budget. none of this work is controversial.
Branches are cheap. They are a great place to
On 2011-12-26, at 13:38 PM, Paul Vixie wrote:
if the posix branch work that was begun over one year
ago had been reviewed and merged and had become the basis of a 1.5 or
2.0 release by now
Heh. Good plans derailed with needs to pay the rent. The two weeks I thought I
had back then have
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
Shouldn't this be the decision of the message submission agent?
You mean nmh?
No, I mean the SMTP server that nmh pushes the message to (or the program
that post invokes to take the message). nmh is not a submision agent.
___
Nmh-workers
The days of guessing the construction of local and remote email addresses went
out the door with the ARPANET, /etc/hosts, and the multiuser VAX. In this day
and age of personal workstations, port 25 filters, and MX records, any attempt
at synthesizing a senders email address from uids,
On 2012-01-09, at 18:15 PM, Ken Hornstein wrote:
And my interpretation is that Lyndon is saying:
- We should have the user configure their email address at some point
- We should then use that as the From: header.
And my interpretation of me is:
1) No From:, no message gets sent.
1a) The
On 2012-01-09, at 18:56 PM, Earl Hood wrote:
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.
Yes, please!
This is something I face
On 2012-01-12, at 18:07 PM, Ken Hornstein wrote:
Comments bug reports welcome!
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' ;-)
More seriously, whatever else you discovered as you got there is worth
documenting
On 1/17/2012 1:45 AM, Ken Hornstein wrote:
Are there any objections to the wholesale conversion from utmp to utmpx?
Have at it! That one was next on my todo list before time ran out.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
But restrict the entire nmh to utf-8 charset would cripple system.
How so, specifically? Plan9 has run a native UTF8-only mail environment
for ages (with a very MH-like mailstore, as well), and it's far from
crippled. It stores messages in their native format, and dynamically
converts
On 2012-01-19, at 12:36 PM, Ken Hornstein wrote:
(Although ... you will probably need automake either today or tomorrow :-/).
I hate you :-P
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
On 2012-02-02, at 7:07 PM, Ken Hornstein wrote:
posix_conversion
That branch is dead dead dead! I nuked it, but somebody brought it back to
life. Please kill it and forget it ever existed.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
On 2012-02-03, at 9:42 AM, Ken Hornstein wrote:
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
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 the template to populate the user's
components
On 2012-02-05, at 8:49 AM, David Levine wrote:
Or to really
play it safe, have configure determine which are available
and use them all?
At the same time? Sounds like a recipe for deadlock to me. And it won't work
correctly, if at all, on platforms that implement one or more of
configure should be able to set this on a per-platform basis.
It can't because it depends on what other applications use.
Fedora /bin/mail uses fcntl and Mutt recommends it.
procmail can use it. I haven't had any problems since I
starting using fcntl. I did see problems with dot
On 2012-02-05, at 1:04 PM, David Levine wrote:
Then fcntl can't always be shunned. Given that a choice
must be made, let the user make it if they don't like the
nmh default.
Shunned, not not ever used. Obviously if the platform uses fcntl in
/bin/mail and other system utilities then inc
On 2012-02-05, at 1:23 PM, David Fellows wrote:
And some platforms (mine for example) do not have /bin/mail. And presumably
do not use the system mailbox. nmh should build nicely on such a system.
It could use its choice of locking for the system mailbox.
Which platform is that?
On 2012-02-05, at 12:13 PM, Ken Hornstein wrote:
% echo `mhpath 5 8 12`
/tmp/.imapcache/88932 /tmp/.imapcache/92861 /tmp/.imapcache/1034785
Or whatever ... you get the idea. mhpath would fetch the messages
in question and put them somewhere local and return those pathnames.
Sure, you
On 2012-02-05, at 3:13 PM, David Fellows wrote:
I find I have no need for /bin/mail so I have not installed a package that
provides it. nmh, fetchmail, and ssmtp are sufficient for my needs.
Okay, now you're just being a pain in the ass. So you didn't install binmail.
This changes the API
On 2012-02-06, at 6:28 AM, Ken Hornstein wrote:
I understand where you're coming from, but I have to ask ... when
people use mhpath to get the path of an MH message, what, exactly,
are they trying to accomplish? Usually it's something along the
lines of use some Unix text processing tool on
Not just download, but upload too, that is, modify messages.
IMAP messages are immutable. You cannot change them after the fact.
This us one of the many tricky issues with supporting an IMAP message store.
E.g., it will be difficult to make anno behave correctly in all cases.
On 2012-02-06, at 9:09 AM, Ken Hornstein wrote:
SETMETADATA INBOX (/private/nmh/${imap-uid}-anno Replied: Mon, 06 Feb 2012)j
Exactly.
As I understand it ... the limits on METADATA are per-mailbox. What are
some typical limits?
I'm not sure. I will poll the IMAP protocol list and see what
On 2012-02-06, at 7:51 PM, Joel Uckelman wrote:
I wonder how this will play with the /usr/bin/sendmail provided by
postfix. According to its man page, -om is ignored, while -oem and -ov
aren't listed at all.
-om (include sender in alias expansion) is always on in postfix.
-oem (mail back
On 2012-02-07, at 3:00 AM, Oliver Kiddle wrote:
I'd prefer to just see the email. mhshow could have a -pedantic or -lint
option.
Or you could use cat(1).
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
On 2012-02-07, at 7:37 AM, Oliver Kiddle 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 now. If the
There seem to be a few misconceptions about how IMAP works. Let me try to
explain in a bit more detail about how I think IMAP would work with MH.
First, and perhaps most important, IMAP support does not preclude keeping local
copies of the message content in the native MH store. MH would grow
I would love to be able to prevail upon them to fix this or to dump all
such nonconforming mail in the bin. That said, when I get mail from
ConfMaster, it tends to be mail that I need to read, so I appreciate it
when nmh can take a guess and perhaps show me some not-too-garbled text.
(In
On 2012-02-07, at 9:29 AM, Lyndon Nerenberg wrote:
being liberal about what you except
Oh good lord, did I really write that?!? :-)
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
On 2012-02-07, at 10:13 AM, Joel Uckelman wrote:
What you're describing here is far beyond what I was intending; I only
want a seamless way to apply my eyeballs to these broken messages.
I don't think it gets any more seamless than cat. I would have show (and
anything else) print the full
src/nmh/contrib seems like it might have merit as a place holder for some of
the wee gems people have been talking about. If you have non-trivial bits to
share, send them to me. If there's more than a trivial response I will get
this stuff into the git repository.
--lyndon
Is there a place to store them on Savannah? Or
should I just throw them into the git repo? About 3.5 MB.
Get them into docs/ subdir in the repo before they get lost. We can find a
better home later if that makes sense.
--lyndon
___
Nmh-workers
It's also probably
going to take a troff guru to figure out how to make it usable.
If you can get the source extracted I can take a run at cleaning up the
troff.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
On 2012-02-29, at 11:26 AM, Ken Hornstein wrote:
I've got nothing against bringing in the original troff input; it's
just that what's in the MH 6.8 sources isn't exactly pure troff.
It's got to be run through the build system to get rid of all the
@BEGIN@/@END@ pairs (and I'm not even sure
On 2012-03-02, at 12:12 PM, Ken Hornstein wrote:
Specifically, if there is text after the last encapsulated message, then
it ends up as a new message. This isn't an issue if you just use
forw, but it crops up if you use forw -digest (because you'll get
a message that says nothing but End of
On 2012-03-11, at 8:39 PM, Ken Hornstein wrote:
My thinking was that since bounces go to the SMTP envelope-from,
bounces should go back to the person who wrote the message. In the
example above, I'd want to know about a bounced email, rather than
my secretary (I guess I could see other
On 2012-03-12, at 9:05 AM, Lyndon Nerenberg wrote:
Since these headers will be specific to the backend transport I would suggest
ignoring ones unknown to the backend, and giving the backend the ability to
print warnings, or abort the send, if there are problems processing a
recognized
On 2012-03-12, at 2:39 PM, Robert Elz wrote:
Make the name fairly precise and the chances of someone using the same
thing (including the IETF) for some different purpose are absurdly
small.
That sort of statement tends to lead to infamy ...
But I suppose I wouldn't grumble too loudly if we
On 2012-03-12, at 4:32 PM, Robert Elz wrote:
Adding stuff like nmh in the field name would certainly reduce the
chances of a clash even further, but at the expense of making them
less manageable (for humans to deal with.)
I doubt they'll be used often enough for that to be an impediment.
Paul Vixie wants to kill m_getfld() and I can't really blame him, but
I don't think that's going to happen for this release unless Lyndon has
a private branch that he hasn't told us about :-)
I have nothing up my sleeve, and won't for a while. Too much other stuff
on my plate at the moment.
On 2012-03-15, at 11:04 AM, Jon Steinhart wrote:
But times have changed, and it doesn't work well with new stuff
like dropbox.
And dropbox is not a typical directory in the filesystem. If you use a service
that explicitly makes files publicly available you shouldn't be surprised when
it
On 2012-03-15, at 11:14 AM, paul vixie wrote:
making this always be ~/@ rather than ./@ would fix this, even on
dropbox systems, wouldn't it?
Not if you point dropbox at $HOME. And these days, it wouldn't surprise me
that people do ...
___
On 2012-03-15, at 11:46 AM, Jon Steinhart wrote:
Sure. But I am still curious as to the purpose intended by @ in the
first place if anybody knows.
From dist(1):
See comp(1) for a description of the -editor and -noedit switches. Note
that while in
the editor, the message
On 2012-03-15, at 7:09 PM, Jon Steinhart wrote:
What killed x-?
The IETF has been trying to stamp out x-* headers and commands (off all forms)
for years. The momentum has finally grown to the point where it looks like it
will happen.
___
On 2012-03-16, at 8:28 AM, David Levine wrote:
If we prefer to default to the current behavior (@ enabled)
but deprecate that default, OK by me.
How about we add the switches in 1.5 but leave it on and mark the feature as
obsolete in the release notes. In 1.6, disable it by default. And then
On 2012-03-25, at 20:40 PM, Bill Wohler wrote:
x-* is dead.
Hi Lyndon, I missed this discussion. Do you have a URL or two to
pertinent discussions?
This has been a general grumbling throughout the IETF for years now. There's
no single place it's getting discussed, but the issue crops up
On 2012-04-16, at 9:03 AM, Ralph Corderoy wrote:
Copy `cat -A'?
seq 0 255 | sed 's/$/P/' | dc | cat -A
Or some other similar escaping; \x1b. It does mean one wouldn't be
able to discern a subject with cat -A-looking output from binary.
What about non-utf8 multi-byte encodings. Can
On 2012-04-16, at 10:22 AM, Ken Hornstein wrote:
Hm. I see your point, but I'm sort of torn here. Do we care about
obscuring the surrounding text? I mean, the original bug report
came as the result of a spam message; I don't think this is a problem
in the normal case, is it? To me ? more
On 2012-04-24, at 9:21 AM, Ken Hornstein wrote:
Minor nit: ! is in POSIX; the problem here is Solaris has an ancient sh
implementation (isn't there a POSIX one in something like /usr/xpg4/bin ?).
Same with -E for grep.
You cannot sanely use a Solaris system without putting /usr/xpg4/bin at
On 2012-04-26, at 10:39 AM, Paul Fox wrote:
if the cron job runs in between the pick and the scan, the mhlock you've
added won't help.
If you need transactional semantics on the command line you would have to
mhlock 'pick ... -seq foo; scan xyz'
The MACHINES file states:
Known Compilation problems:
--
FreeBSD:
OpenBSD:
NetBSD:
Some BSD4.4 machines have problems when running nmh's configure script.
They will be unable to find the location of vi and sendmail. This is
due to POSIX features
On 2012-04-27, at 5:15 PM, Robert Elz wrote:
NetBSD's pkgsrc for nmh doesn't require (or use) bash, and nmh (currently
still 1.3 there) builds fine using the normal NetBSD sh (which is a zsh
variant I believe).
And I have fuzzy memories of ash (as /bin/sh) bugs in the earlier FreeBSD days
On 2012-04-29, at 7:33 PM, Ken Hornstein wrote:
But then you say (in another message) that you want nmh programs
to not deadlock under our hypothetical nmhlock program ... so you
want to run nmh programs under nmhlock? Or you want the option to
handle both nmh and non-nmh programs under
On 2012-05-29, at 7:19 PM, Paul Vixie wrote:
for that we have getenv('SHELL'), which is far more closely related to
the user's preferred command language than either their login shell or
the posix standard are going to be.
This conversation is cool. It reminds me of a phone call I had with
On 2012-06-06, at 9:39 AM, Ken Hornstein wrote:
AFAICT ... it's always been that way. We didn't have -version back in
MH-6.8.5, but at least as far as our sources go back (1999) -version has
always exited with an exit code of 1.
Should it? I dunno ... what do people think?
The current
On 2012-06-06, at 10:25 AM, Ken Hornstein wrote:
It's been this way for 13 years, at least. Another few
months won't hurt with something so minor. So I think it
should be post-1.5.
Sounds to me like that's the consensus. David, you want to do the honors
when you get a chance?
Also,
Ken Hornstein writes:
Your draft file does not contain a From: header; this version of nmh
requires that all draft messages contain one. See the default
component templates for examples and insure that your draft contains
a valid From: header.
s/insure/ensure/
Insurance ensures you will
Host part is pseudo, it's after the @ and can include most
ASCII printable characters.
Just read, say, 64 bytes from /dev/random and base64 encode it.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
64 bytes? Though 64 bits seems too short.
It's just a number :-)
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Dumb question time: Do we want to introduce a dependency on /dev/random?
Looks like most people have it now.
That's why the fallback. Everyone has getpid() and time().
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
That was mine, and no it doesn't have /dev/random. But, as I said
earlier, I'd prefer to opt-out of this whole cryptographic host part
concept anyway.
It's not cryptographic, it's just a case of trying to achieve uniqueness
without too much effort. The world won't end if message-ids collide.
This message should have a random Message-ID.
The trouble is, it's not a valid Message-ID. You sent:
Message-ID: 16888-1342905949.421986@QcTLPy+DeAJLdhEN
The grammar production requires:
msg-id = [CFWS] id-left @ id-right [CFWS]
So you need to stuff an '@' in there someplace.
Odd.. My copy of the message, and the one you quoted, both apparently
had an '@' in them, between the '6' and the 'Q'? ;)
Odd. My brain and eyeballs cannot spot an '@' between a '6' and a 'Q'.
And I was pretty sure my editor search for it, umm, failed.
Doh.
--lyndon
1 - 100 of 556 matches
Mail list logo
