>.. note the weird spacing before '(others)' in the second. I'm guessing
>this is (line 613 of ./nmh/uip/folder.c on master, I think) because
>'folder' and 'folders' ?maybe? share the same binary and the extra
>'curmsgdigits + 6' spacing is to keep columns aligned in 'folders'
>output. Possibly
>Thus said Robert Elz on Fri, 19 Jan 2024 12:30:08 +0700:
>
>> That's "prompter" - has always been mh's default.
>
>Not always:
>
>https://git.savannah.nongnu.org/cgit/nmh.git/log/sbr/geteditor.c?h=1.8-release
>
>Looks like it was changed in 1.8 (if I read that correctly).
>
>I wasn't aware of
>It is quite possible.
I guess I am a LITTLE surprised this is the first instance you've ever
seen where a text part was encoded with base64; I get those all of the
time (and not just in work emails either). Maybe you get those more
often than you think and this is just the first time you wanted
>Yesterday everything worked. Today, trying to reply to a message I get:
>[...]
>I am running OpenBSd 7.4 and nmh-1.8. My ~/.mh_profile contains the
>line:
>
>repl: -query -annotate -nocc me -filter mhl.reply
>
>and the mhl.reply filter is:
>[...]
I don't see anything in this setup that would
>> So while I agree post would fail with this hypothetical dist(1) of a
>> message containing a NUL, it's not clear you could inc(1) such a
>> message in the first place.
>
>Today or historically? Historically is a long time.
I can't say that I know every single line of nmh and MH code since the
>> I'm thinking of removing the support in post(8) for sending NULs. Any
>> disagreement? It's not a lot of code so could be easily restored in
>> the future if conditions change.
I think this makes sense, and it does seem to cause some kind of
problem as reported in Cy's message. It would be
>> ...draft file does NOT contain a '\n' as the last character? My
>> memory is that for some strange reason Emacs like to default to doing
>> that. I suspect we do not test for that.
>
>A POSIX text file is zero or more lines where a line is zero or more
>bytes terminated by '\n'.
I don't make
Stupid question time: is it possible this bug is only triggered if the
draft file does NOT contain a '\n' as the last character? My memory is
that for some strange reason Emacs like to default to doing that. I suspect
we do not test for that.
--Ken
>It certainly includes that commit above.
>I updated just last week before starting this thread actually.
>Looking at my outbox, I think it did start when I upgraded.
>
>I tried "git revert 8f897f65", but it results in a bunch of conflicts, which
>I decided not to investigate.
Could you just do
>> What version of nmh are you using? There was a recent bug reported
>> by Cy Schubert that may be the cause of this:
>>
>> http://savannah.nongnu.org/bugs/?65002
>
>Interesting. Can anyone replicate this bug? Michael, are you running
>on FreeBSD or something else?
I haven't tried yet;
>I also find it hard to beleive that someone wants the MUA to have a
>specific Message-ID for their email, but there is at least one software
>that I'm aware of that does act upon the contents of it:
>
>http://smarden.org/qconfirm/qconfirm-check-mid.1.html
I mean, yes, it looks for messages
>> [...] Sendmail,
>> yes, it looks like you could change it if you really want to; it also
>> defaults to something based on the local hostname. I am personally
>> skeptical that people actually configure this.
>>
>
>FWIW, MIT's campus computer network (Athena) did this for a long time,
>because
>> I mean, that's not a reason in my thinking? Like, WHY do people want
>> that?
>
>To be able to uniquely refer to that email in future by knowing what the
>message-id field contains. The reference may be to oneself or to other
>recipients. That is the purpose of the field. Not knowing the
>Ralph Corderoy wrote:
>
>> The email I'm replying to:
>
>> $ hd `mhpath .` | tail -3 1ac0 6e 73 74 65 61 64 2e 0a 0a 0a
>> c0 80 c0 80 c0 80 |nstead..| 1ad0 c0 80 c0 80 c0 80
>> c0 80 c0 80 0a 0a || 1adc $
>
>> So perhaps look at your
>> 2) The recommendation for Message-IDs is to use a domain name for the
>>right-hand side
>
>Recommendation or rule? I don't recall.
Officially, from RFC 5322 §3.6.4:
Note: As with addr-spec, a liberal syntax is given for the right-
hand side of the "@" in a msg-id. However,
>If you're on a mac and using O365 you may need
>https://github.com/simonrob/email-oauth2-proxy
>
>Using it for a year, happily.
We DO support XOAUTH2 natively, BTW.
--Ken
>I've had a hate, love, hate, love, hate relationship with Apple over
>the years. I think the pendulum is swinging the other way back towards
>love, LOL!
I am sure my perspective is skewed by buying into the Apple ecosystem;
the automatic syncing between devices, little things like replying to
>I have an old linux desktop that I'm sure would work, but I'm wondering
>if I should consider buying a new Apple laptop. Last time I used a Mac,
>it was mostly tolerable for an old UNIX head like me. Are there any
>issues running nmh on a Mac?
I'm typing this from a Mac right now (well, via
Ralph has already noted that this message still has those bytes at the
end, but I think there was a mh-e error as this message wasn't even
clearsigned. Instead this was at the top:
><#secure method=pgp mode=sign>
As a note I'm wondering what those bytes even are; they aren't valid
UTF-8.
--Ken
>Maybe strcmp(hostname,"localhost") should cause that value to be
>ignored, and if necessary, resort to random messageid. Or maybe that should
>just be the default in some way.
There are a bunch of competing factors here that I am not sure it is
possible to resolve to everyone's satisfaction:
>127.0.0.1 localhost obiwan.sandelman.ca obiwan
>
>which is often required for certain things work, but I don't remember
>what now. I'll change it see what breaks. Is there any override?
>Let's see this message.
I see that worked. There is not an override; if you use -messageid random
you'll
>I noticed that my emails have stuff like:
>Message-ID: <25170.1703892488@localhost>
>
>rather than my hostname or domain name.
>Since it's like this in my outgoing folder, it must be generated by NMH
>rather than by my local postfix.
That would be a nmh-style Message-ID; the first number is the
>Indeed that is what is happening. It seems like you prefer it work
>this way rather than showing the welcome message just once; in that
>case, there is nothing to do on the situation I present.
I think you misunderstand me; I'm not saying I PREFER it work that way,
I just am explaining why it
>Dear colleagues,
>I have for a long time had a different issue with the welcome message.
>Perhaps it is worthwhile to report. To produce this issue, set up a new
>MH directory, and run a failing command as the first command.
>[...]
>$ scan +this-is-not-a-folder # Show the welcome message
>$ scan
>The topic itself -- i do not know. I tend to totally agree with
>your statement, but then again, not. I mean there is nothing
>i would have to be ashamed of or that could make me blackmailable.
>But i do have SSH keys to other people's computer(s) (networks).
>I have S/MIME and PGP (and
>The all-embedded RFC 7265 JCAL (plus JMAP etc) is surely the
>future for all of you.
I get the feeling there's some scorn in that statement. I'm not trying
to drag anyone else's choices; it's tough to find the right balance
between "keeping up with the times" and "sticking with stuff you know
>I'm firmly planted in the Linux, MacOS, Windows, and Android worlds.
>So, my current calendar is a piece of paper on a clipboard that I always
>carry with me, LOL! I find it way more expedient to use the clipboard
>rather than try to have a to-do list app and a calendar app and remember
>which
>I'm an old Unix system admin command line type, and I love MH/nmh.
>
>I let the Mac and PC worlds distract me for a bit, but I'm really
>tired of dealing with Calendar, Outlook, and the like, especially when
>Microsoft is threating to change the user interface again. Is there
>a calendaring
> By using the -file name switch, one can direct inc to incorporate
>messages from a file
> other than the user's mail drop. Note that the named file will not be
>zeroed, unless the
> -truncate switch is given.
Is it _possible_ you have -truncate in your .mh_profile under inc?
The
>I'm not sure if it's a good idea to start this topic, but it bugs me a
>bit. Also as a disclaimer my view on this is highly influenced by my own
>m_getfld variant[0].
>
>Because of the missunderstanding of when LENERR is used I have looked
>at m_getfld.c and I see some problems with the interface
>> Thank you for pointing that out. Header field folding does need to be
>> properly implemented. It would be a great contribution if someone has
>> the bandwidth.
>
>I have looked a bit at it. I found two places where this could be
>implemented:
>
>Either as part of encode_rfc2047(), this
>To answer my own question, mhshow can be customized to use the user's
>preferred mail reader. Ken mentioned w3m with display_link_number. I
>use firefox, I find that its performance on a modern machine with an SSD
>drive is adequate.
I think a BIG problem with this is that doesn't get you the
>You can use $ open -a seamonkey `mhpath cur`
>
>It opens it as a text file. The .eml extension is required to show
>text/thml. But with .eml extension you can just do
>
>$ open foo.eml
>
>and it will open in your default MUA. i.e. Apple Mail. If you haven't
>configured it, I don't know if it
>Thanks Ken! I'll be giving this a try! (I would have "just tried it
>myself", but I don't have any modern readers installed! Small point
>of pride, until now. :-)
One note: you MIGHT have to have Thunderbird configured properly as a MUA
to do this (I already had this done).
>Huh. ".eml".
>Once in a while my wife or I (both MH users) get an email that really
>can't be handled directly by MH. Today's example looks like this:
>[...]
I hear you, dude (I also have a wife that is a nmh user as well; go
figure. I wonder how many dual-MH households there are?)
>$
>I have added the line forw: -format to my ~/.mh_profile.
>
>Now I find if I do:
>
>forw -mime 33
>
>I get that empty #forw line and nothing else.
I know this has been mentioned several times, but when you get this line
you STILL need to run the "mime" command at the What now? prompt before
you
>If I forward to my iCloud account, it works. If I forward to my
>Proton account wHat I get is an empty message with an attachment; the
>attachment consisting of a string of numb...@eddie.fios-router data 8 KB
>
>I have stumbled upon the fact that if I use MH-E within emacs I
>can forward in-line
>Unfortunately, I am back again with the same issue.
>[...]
I went back and looked at your original email about this, which is
here:
https://lists.nongnu.org/archive/html/nmh-workers/2023-04/msg00083.html
The original information you were given still holds true, in that doing
this should work:
>Not to prolong the agony, I tried the example on OSX for man tbl:
>
> .TS
> tab(@);
> ccc.
> This@is@centered
> Well,@this@also
> .TE
>
>It didn't work with the nroff -man they supply. It did work with mandoc
Silly
>>> Sorry if I jumped into the middle and missed something, but what about
>>> using this to convert once?
>>>
>>> groff -Thtml
>
>> I guess my next question is ... what do we do after that?
>
>I thought if we ran it through with man (nroff/groff) to ascii, then we'd get
>I don't see a tbl command on MacOS (or freebsd, except if you
>installed groff (or plan9port -- ignore the troff comment!).
At least on MacOS X, 'man tbl' actually works (but there is not a separate
tbl command, true). The man page says:
The tbl language formats tables. It is used within
>Why not just add a note in man pages affected by the .fc problem
>that if the tables are not properly lined up, the user must install
>groff (or plan9ports, where you also get troff)?
I don't necessarily object to this, but ... well, that troff request is
weird. Like I'm still not quite sure
>> Pandoc is available in lxplus, aiadm and most RPM repositories. It's
>> written in Haskell, which means it relies on hundreds of megabytes of
>> library dependencies.
>
>That's certainly fair, but wouldn't it need to be used only once, after
>which the documentation could be maintained in
>>In a more practical sense, I am not sure there is anyone with the free
>>cycles to convert the current man pages into some other markup language.
>
>This seems like the sort of thing that should be possible to automate, and
>that question has been raised before. A quick search turned up the
>> I am kinda against depending on some third-party tool
>
>Where does built-in turn into third-party? With all the modern package
>managers, it's trivial to install other tools as needed.
That's a fair question! And one I struggle with. One thing that is
common is we do make a distinction
I meant to send this out earlier, but I wanted to summarize what I think
are the prevailing attitudes about NUL characters in email messages
that I asked about in February:
- It seems like NULs are just not that common in the real world, so no
urgent changes are required
- We should probably
>Sorry if I jumped into the middle and missed something, but what about
>using this to convert once?
>
>groff -Thtml
I guess my next question is ... what do we do after that?
I am assuming that we still want to ship man pages; do we use some tool
to convert them back? Do we have to make man
>The status quo is fine. It doesn't require understanding all of troff.
>Just man(7) plus the odd bit here and there.
Sigh. The "odd bit" unfortunately, for me, requires a lot of knowledge
that seems to take some serious roff-fu.
Let's take the example you gave where the first line for a man
>You could replace .fc plus *all* the man macros with all-mdoc macros in
>all the nmh man pages. It's man ^ mdoc == 1.
Ah, poop. I see what you mean; you can't mix and match macros across
packages. Dang it.
--Ken
>mandoc is a pain. It's one of many programs which attempt to interpret
>man pages whilst being an incomplete implementation. I hang out in
>places which like to talk about troff/nroff, including for man pages,
>and mandoc's flaws crop up a lot.
So I'll admit my ignorance here. What's the
> | Given my druthers I think I'd rather do the last one, since this kind
> | of seems like a table!
>
>I would do it that way (now) too, either that way, or just use mdoc
>primitives - an appropriate layout could probably be achieved using
>the list macros (with tags) in compact mode.
Fair
>It does seem like the size of the headers exceeds the size of the body
>in a lot of cases :-)
I mean ... yes? Doesn't seem like there's much we can do about that
unfortunately.
--Ken
So I noticed that after an upgrade to MacOS X, I started getting this
warning on certain nmh man pages:
This manpage is not compatible with mandoc(1) and might display incorrectly.
After some digging, it turns out man(1) is a shell script and to make a
long story short is running this command:
>I use MH-E, which does it's header display/hiding outside of MH. In
>general, I like to see extra headers, but they have gotten way out of
>hand from the MS/Outlook space. We probably need a better list of
>common "this is junk" header list that probably has to have wildcards in
>it.
Sigh. I
>Thanks Ken. So my mhl.headers looks like this:
>[...]
I am wondering if you are, in fact, not using that mhl.headers file like
David just suggested? It sure looks like you are not. It almost seems
like your showproc is just "more".
--Ken
>Hey all, been meaning to get to this for a while.
>
>Things are way more verbose in the current release in that all sorts
>of headers clog up my display. The extras:nocomponent only seems to
>cut down on a few components.
Well, I know this is confusing, bttt ... "extras:nocomponent" means
>However, ISTM having addr output text that can be something other than
>its documented "contract" (an mbox@host or host!mbox) is perhaps a bit
>dodgy, even when the root issue is invalid (or unsupported) input. I
>don't know how the formatting engine works, but couldn't addr
>conceivably scan its
>1. Could (should?) %(addr{}) be expected to be able to
> extract the addr-spec part out of an invalid message header?
Ummm no?
If the address parser fails, well ... we're kind of stuck. Internally
that's what makes all of the format engine address functions work. I'm
not even sure what
>In the meantime, an occasional folder(1) -pack might solve the problem
>manually.
It did occur to me that if you did a folder -pack in the MH-E index
folder and you had a numeric sub-folder then your sub-folder would
change its name and I am not sure what that would do to the MH-E index.
--Ken
>while actual bytes of memory on my laptop are semi-precious, addresses
>in the address space are much less so. here's somebody who uses mmap(2)
>to allocate a huge chunk of address space, and then madvise(2) (a call i
>think i've never used) to have that chunk backed by (lots and lots of)
>a folder with the highest message number of "N" will cause the array to be
>configured to support N messages, even if there are many fewer (perhaps
>even one) messages
No, that's not correct. If you have a single message in a folder with a
count of 100, you only get one entry allocated.
>From Ken's description above, these 111 messages would allocate almost
>800,000 msgstat structures. I don't know how huge the message numbers
>get in the results folder, but six digits is common. I don't recall if
>I've seen seven digit or larger message numbers.
I see Conrad pointed out that
>> I think we have to push this back on the MH-E people; Robert's
>> suggestion to add a non-numeric prefix to directories it creats sounds
>> like the best answer to me.
>
>$ refile +31415 $ folder +31415
>31415+ has 1 message (1-1).
I'm aware of that, but what happens if you have
>it seems that at some point i had done a search for 74600607886815 (your
>basic "magic number" :). mh-e, i guess, had created a directory with
>that number as its name (it uses the search term to name subfolders
>under the normal mhe-index folder). and, i guess, flist decided that
>(under the
>ah, great! yes, that works. and, yes, to my ignorant eye, it appears
>that the call from `folder_read()` to `mh_xmalloc()` is where we are
>going south.
>[...]
>#2 0xf898 in mh_xmalloc (size=42269452928) at sbr/utils.c:38
>#3 0xacf6 in folder_read (name=0x555d5400
>I see that nmh commands are reading the $MHCONTEXT file, parsing the
>line "Version: nmh-1.7.1" and printing the Welcome message, but not
>updating the file unless there is a context change:
In your .mh_profile you can put:
Welcome: disable
To disable the version checking completely. There's
>> If you run under the debugger, you should stop when you receive the
>> signal from the OOM process.
>
>thanks. OOM is a pretty strange way to die...
Sigh, I guess I was thinking that ptrace() would be able to catch a
process killed by SIGKILL, but I guess not.
Is there a long delay when you
>and, if not, any thoughts on how to debug? if i build "cc -g", any
>thoughts on where to set breakpoints, or where to insert printf's, to
>try to track this down?
If you run under the debugger, you should stop when you receive the signal
from the OOM process.
That MIGHT be useful _if_ you hit
>While POP's LIST does actually include the size of the message in bytes,
>that's prior to any CRLF mangling that happens so it cannot be used
>reliably as a method for determining when to stop reading. Unfortunate.
Right, but that's mostly because of the way multiline responses are
handled
>When I was poking around in the POP code I didn't notice any special
>handling of NUL bytes. It's possible that this would result in
>truncation. If that's what we do now, I suspect it's alright to continue
>to do so; at least until we find legitimate emails in the wild that do
>> I do not think this is relevant to this discussion, unless they
>> are changing RFC 5322s position on NULs.
>
>But, it seems like a question that IETF could clarify.
I don't see how further clarification is necessary here? I mean, a 16MB
single line in email is clearly a MUST NOT, but
>> if a NUL appears in the header somewhere all bets are off.
>
>I think it would be fascinating to understand how that happened. Depending
>on how the parse tree is done, it could be marginally bad, or catastrophic.
>
>I really would be amazed if this is seen in the wild. But its a big
>network:
>I have received email with C-T-E set to binary. While I don't think it
>was needed, I haven't checked closely.
Facinating! I am curious: who/what sent this to you! Do you remember
the MIME type?
>> - Completely handle embedded NULs properly. This is arguably the most
>> correct option but
>Seems to me this is classifcation of attachment data, which will end up
>as octet-stream in that case.
It's ... a little confusing!
>For S-nail we more or less do what Heirloom mailx has done.
Well, it seems that in the message lexer if you encounter a NUL you
just stop, from a_msg_scan():
I've been idly thinking about this for a while, and while the question
might be simple I think it gets at some larger meta-issues we have never
really agreed on how to resolve it properly.
My question is, simply: What should happen when nmh encounters a NUL
character (U+) in email?
The rules
>> Has anyone tried 1.8-RC3 on a BSD platform? If good, any objection to
>> releasing 1.8 soon?
>
>Unless there's an objection or discovery of a problem, I'd like to
>release 1.8 this weekend.
Just a minor note: I tested nmh 1.8-RC3 on MacOS X (which I know was
already tested) but I also tested
>Ken, you, and David all seem irked by unset and set-but-empty being
>treated differently, as if you'd like a binary outcome by first
>conflating the ternary input to binary.
Sigh. I'll try to make my point clearer, but I recognize we're not going
to agree on this. Since David is driving this
>What's the intent of an empty HOME?
>Is it set by accident when it's meant to be unset?
>Is it empty by accident when it's meant to be non-empty?
>Do they want HOME=/, HOME=$PWD, or are they expecting it to error.
>Any choice could be not what the user intended so exit.
I mean ... you could say
>So an unset HOME is allowed by this function, it's an empty HOME which
>isn't.
It strikes me as strange that there is a difference between an unset
HOME and an empty HOME in terms of behavior. I mean, yes, I can see how
the code is written, the historical precedent and how we got here, but
...
>$ printf 'Path: /tmp\n' > /tmp/mh-profile-minimal
>$ HOME= MH=/tmp/mh-profile-minimal /usr/bin/mh/mhparam path
Thank you for the analysis. I am wondering, though ... WHY does xlbiff
set HOME to '' for this test?
(I am neutral on whether or not this is technically a regression; I can
see it
>> I wanted to test it on MacOS X.
>
>I did. Success both with debug and non-debug builds.
>
>> But ... did we ever get a resolution on the long lines POP patch?
>
>No. How about we defer to post-1.8?
Can we tenatively say that it's targeted for 1.8.1?
--Ken
>If all goes well, I hope to release 1.8 within a week.
I wanted to test it on MacOS X. But ... did we ever get a resolution on the
long lines POP patch?
--Ken
>Agreed, it doesn't. They arrive as valid UTF-8 here which show just
>fine so I hadn't noticed a problem, but it's clearly wrong. I expect
>it's a bug in the script but have forgotten where is it to be found.
I believe it is under the control of savannah. I am not sure it is
really worth doing
Ralph,
I've noticed recently that you've been putting UTF-8 characters in commit
messages. E.g:
man/burst.man: re-word to avoid ‘digestifying’, etc.
I'm personally fine with that, but when the email is sent out about the
change I get them a little mangled because the script that
>Has anyone had a chance to review my proposed changes to inc to be able
>to handle long lines from POP sources? While it's not common (most big
>email providers like Hotmail, Gmail, etc, all conform to RFCs), there
>are occasional emails (mostly from online web stores with shoddy
Everyone,
So now that we've started the release cycle process (thanks, David!) I
am wondering what the plans are for getting 1.8 packages into various
distributions. I did the Homebrew formula for MacOS X and I'm glad
to do it for 1.8. But I am wondering what other operating systems we
should
>I just did an upgrade at home to MacOS X Ventura; let me make sure the
>test suite passes and there are no obvious issues there.
Oof, wait. I just did a "make distcheck" and I get:
depbase=`echo uip/mhical.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
cc -DHAVE_CONFIG_H -I. -I../.. -g
>>Do you or anyone else have anything else you'd like to put in before
>>starting the 1.8 release cycle?
>
>I just did an upgrade at home to MacOS X Ventura; let me make sure the
>test suite passes and there are no obvious issues there.
I just did that, and it builds fine and passes the test
>Ralph, your last round of changes look good to me. HEAD builds and
>tests cleanly for me on Fedora, Solaris 11, and Cygwin.
>
>Do you or anyone else have anything else you'd like to put in before
>starting the 1.8 release cycle?
I just did an upgrade at home to MacOS X Ventura; let me make sure
>I would think that finding two plain text files with the same MD5
>that a mail message receiver finds an acceptable read is rather
>unlikely though. (Just generally speaking. CRUX Linux for
>example uses signify for package checksums, but still generates
>MD5 checksums as a fallback. CRC32 is
>> Seems like they should maybe emit warnings for a release
>
>Yes, i.e. be deprecated. But that ship has sailed and I don't think Ken
>would be pleased if I added them back in so they could be deprecated.
Sigh. Ralph, you and I don't agree on Content-MD5, which is fine. But
I have to point
>Greetings as we approach the new year.
>
>It's been a long time since nmh 1.7.1 was released, March 2018 to be
>specific. What does everyone think of pushing out a 1.8 soon? Here
>are changes since 1.7.1:
>
>https://git.savannah.nongnu.org/cgit/nmh.git/plain/docs/pending-release-notes
>
>While
>Just upgraded my system to FC37 which incldes nmh 1.7.1.
>show now runs everything through more which I hate.
>Can't seem to disable it, even with --showproc cat.
>Can someone save the trouble of having to figure this
>out from the source code?
Geez Jon, what version of nmh were you using
>> There are two ways of establishing a TLS connection to a server:
>
>> I've suggested the first method in the hope your server supports
>> that. If it doesn't seem to, at least on the port you're trying,
>> then inc has a -tls option which attempts the second method.
>
> inc:
>I have a working prototype that I'm testing that uses netsec_read(). I
>had to expand the function declaration for netsec_read() because it
>didn't return the number of bytes that the caller received. Not sure if
>that was intentional and I'm just misunderstanding netsec_read().
Oof, how
Following up to myself ...
Since Ralph mentioned fetchmail, I was curious what it does when confronted
with a huge-assed line. Here's what I found in transact.c:
/*
* Try to gracefully handle the case where the length of a
* line exceeds MSGBUFSIZE.
>> The only complicated thing I see is dealing with the case where a CR
>> is at the end of one buffer and the LF is at the start of the next
>> buffer; I think that is straightforward.
>
>Precisely. Though in my current patch proposal, the problem isn't with
>CR/LF but with the two ..
>I originally looked at netsec_read() as an alternative, but thought it
>would be easier (maybe not simpler) to use netsec_readline() since it
>already had logic for dealing with CR/LF. And the more I looked at
>using netsec_read(), the more it seemed like I would be reinventing
>The longest line that I have observed was 11,370,773 bytes, however, it
>could be any variable length based upon the size of the attachment being
>included in the email.
Oof, yeah, that's what I was afraid of.
I know Ralph likes to simply reject those emails out of hand and I can
appreciate
>I think the POP3 line-length limit is 512 including CR LF. That's what
>fetchmail(1) enforces, and that has been pointed at a lot of servers
>over the year. For the message sent back in answer to RETR, fetchmail
>uses 8192.
My reading of the RFC is that the 512 limit is _just_ for responses to
1 - 100 of 2428 matches
Mail list logo
