Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
On Tue, Oct 4, 2016 at 8:57 AM, David Levine wrote: > If not a tty, we're back to the question. Safer to fail, friendlier to > decode. Decode. How often are real files with "=?...?=" in their name them encountered? --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
On Tue, Oct 4, 2016 at 7:44 AM, Ralph Corderoy wrote: > Content-Type: inode/x-empty; name*=UTF-8''%41%00%42 > Content-Disposition: attachment; filename*=UTF-8''%41%00%42 > > `mhstore -auto' creates `./A'. Perhaps the RFCs rule out %00? But then > again, we're talking about crap that doesn't follow the RFCs. If it's > %41%2F%42 then `A/B' is created if A exists, so that seems OK. It not okay. Filenames specified in email is considered informative only since there are security implications of blindly using what is provided. 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 example, what if I have: Content-Type: application/octet-stream Content-Disposition: attachment; filename="/etc/passwd" or relative pathname attacks using "../.."? I do not recall if nmh checks if a file with same name already exists. If we are to be security conscience, filename parameter should be ignored, with files stored based on content-type, or at a minimum, just use the filename parameter extension. An option can be provided to specify that the filename parameter be honored, but even then, only use the basename after it has been sanitized. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
On Wed, Sep 28, 2016 at 1:11 PM, Ken Hornstein wrote: >>The question remains of whether mhstore should decode 2047-encoded >>filenames natively. It'd be friendly and it's very unlikely that what >>looks ike an encoded string isn't. On the other hand, running mhfixmsg >>shouldn't be prohibitive. > > I know; I'm torn about this. I mean, yeah, mhfixmsg will take care of it. > But still ... ugh; if the brokenness wasn't so widespread, I would say no. > Not sure. Thoughts from anyone else? I experienced this problem years ago with my project. I ended up implementing 2047 decoding for filename parameter since it appears others are unable to read specifications. Google has no excuse for generating such data, but as you note in your OP, other MUAs have been doing it for a long time and from vendors that are notorious for not following specs properly. I do not know how many MUAs support RFC 2231. I do not recommend blanket 2047 decoding for parameter data. Just limit it to parameters associated with a filename. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh architecture discussion: format engine character set
On Wed, Aug 12, 2015 at 8:55 PM, Ken Hornstein wrote: - Handle everything internally as UTF-8. - For _display_, try to convert all of the characters to the native character set (yes, using the locale, dammit!). - For things like _replies_, if we are not in an UTF-8 locale then downgrade things like the addresses using RFC 6587 rules (well, the subject as well ... I think the way it would work is the format engine would do the encoding for you behind the scenes for all components). - Reconvert such messages to 'canonical' standard while sending. Well, I think just for addresses; leaving everything else as an encoded word might not be harmful. But I'd have to think about it. - But this also makes it clear that the thoughts of having an 'external' decoder stage will simply not work; you need to know too much about each header, because they're all handled differently. Sorry for late reply... The above looks reasonable to me. The 'external' encoder/decoder is more of a pie-in-the-sky idea of allowing the encoder system being abstracted so one could plug in different engines if needed. Basically, using pipes into and out of it whenever an encoding/decoding operation is required. However, if the level of effort to achieve such an abstraction is not worth any potential benefit, do not bother with it. Note, there may be some benefit in providing some level of abstraction for the encoder if there is a concern of nmh getting locked-in code-wise to a specific library. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh architecture discussion: format engine character set
On 8/11/2015 11:33 AM, Ken Hornstein wrote: Well, this works great if your locale is UTF-8. But ... what happens if your email address contains UTF-8, and your locale setting is ISO-8859-1? Let me expand on this a bit, because I didn't explain it well. Obviously if your locale is ISO-8859-1, you probably won't have an email address that contains UTF-8. But ... what if you get an email with a 'From' address that contains UTF-8, , and you want to reply to it? Right now convert stuff to the local character set when constructing the reply draft; we can't do that here! Yep. One apparent deficiency of internalized email headers is the inability to encode characters. The MIME non-ASCII encoding syntax is limited to specific contexts and not applicable for addresses. An address encoding syntax should exist for the scenario you describe, allowing one the encode characters that cannot be represented natively in the current locale. However, it seems folks no longer want to support such environments. I guess if nmh ever encounters the scenario, it just errors out. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] MH-W intro/help request
On Thu, Dec 4, 2014 at 5:28 PM, Lyndon Nerenberg wrote: Oh gawd are we going to have the systemd bikeshed here, too? :-P Why haven't you heard, there is going to be a systemd-nmh service ;) --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] O_CLOEXEC
On Wed, Nov 12, 2014 at 11:49 AM, David Levine wrote: Good points. All the more reason to wrap the opens + fcntl(). Popping in real quick here, but if we are voting on this, I prefer the fcntl() route. I have a fairly old linux box that I still use nmh on. It is running a v2.4.20 linux kernel. Thanks, --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Superfluous  's
On Tue, Oct 28, 2014 at 8:11 AM, Robert Elz wrote: If the browser vendors cannot be convinced of the utility of providing a command line switch to set the default char set (which can be passed through to the actual browser that displays the page however they like) then the only alternative to me would seem to be to wrap the html from the message in enough extra glue to expressly define the char set to use. Yep, and that is something that nmh should not do. As long as nmh can provide the charset value to an external program, then nmh has done all it can do. If the external viewer does not support a charset/encoding option, then a wrapper script can be written to modify the data before the external viewer is launched. In the case of HTML, a meta tag can be added to the data to designate charset. For example: meta http-equiv=content-type content=text/html; charset=UTF-8 Of course, a smart script would not insert the tag if the data already has it. Ken, is there a % sequence that gets expanded to the charset of the entity so it can be passed to an external program? Of course, a rational alternative is to simply ignore the html, and read the text version - it was every bit as good, and (in the case in question) was all simple untarnished ascii... And, it is more secure. HTML in email is EVIL. IMO, I would not blindly launch any HTML entity into a browser with a javascript engine. Browsers like lynx, w3m, links do not carry the javascript baggage, hence are safer when viewing HTML data. GUI-based browsers open you up to trojans. Launching HTML from email into a GUI browser should only be done if you reviewed the data first to see there is nothing malicious or you run a sanitize filter against it. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Chrome version
On Fri, Aug 8, 2014 at 1:07 PM, Norman Shapiro wrote: I could try to install a google-chrome package from Fedora. But that is kind of chancy, and Google Chrome 27.0.1453.110 is working well enough for me. A spurious  or two is a pretty minor annoyance. Have you looked into Chromium instead? http://www.if-not-true-then-false.com/2013/install-chromium-on-centos-red-hat-rhel/ Note, I do not use Chrome or Chromium, so I have no personal experience that can assist you. Good luck, --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh internals: full MIME integration
On Wed, Jul 30, 2014 at 5:25 AM, Ralph Corderoy wrote: Would be much nicer if it travelled internally as UTF-8 and then popped into the US-ASCII draft as Subject: Re: =?utf-8?B?wqE=?=Hola world! and into the UTF-8 draft as Re: ¡Hola world!. But this behavior does not require the data to be stored in UTF-8. repl could decode the data when creating the draft, leaving the stored message in its original encoding. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] I like neither green eggs and ham nor MIME
On Wed, Jul 16, 2014 at 12:15 PM, n...@dad.org wrote: ASCII was good enough for my father and his father before him, and his father before him. The tablets that Moses brought down from Mount Sinai, were in ASCII, as were Newton's Principia, the Magna Carta, and the United States Declaration of Independence. Maybe it was in EBCDIC. Now I think I finally know why there is so much religious disagreement: it is a matter of encoding. Maybe the Unicoditian movement can finally bring world peace to all religions. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 2 little issues
On Wed, May 14, 2014 at 9:38 AM, Ken Hornstein wrote: - This part is text/plain - There is no final newline - You are running mhshow (I only mention this because mhstore uses some routines in mhshow, including the one that I want to modify, but it's easy to tell when the caller is mhstore). - You don't have a mhshow-show-text/plain profile entry (I think if you have such an entry your program should deal with it). A newline is added. +1 --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Attach and disposition
On Wed, May 14, 2014 at 3:27 PM, Paul Fox wrote: If you specify a disposition of attachment (which we do), you can't complain about gmail doing what you told it. au contraire. i can certainly complain, which is what i did. and now we're talking about how to fix it. Since the disposition was attachment, it is perfectly acceptable for an MUA to require you to save to a file instead of displaying inline. Otherwise, why even have a content-disposition header? If your intent is, display inline if you are able, then the disposition should have been inline.. One should not expect an MUA to rendering an attachment disposition inline (an MUA may still do it, but the sender should not expect it). Any fix would be to have your message composed so the disposition is inline. I think something like Lyndon's proposal should work. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 2 little issues
On Tue, May 13, 2014 at 10:16 PM, Ken Hornstein wrote: I am unclear as to the right solution. Obviously adjusting the MIME parsing routines is wrong. Making sure that the last character of text/plain parts on output contains a newline might be better, but I'm not sure that's technically right either. Pagers like 'less' do this. If the file being viewed does not end in a LF, 'less' will add a break so the 'less' status line is still rendered at the bottom of the terminal window on its own line. Vim does something similar, but will have [noeol] in the status line to indicate the the source file does not have a EOL sequence at the end. Since adding a LF would only be done whe rendering the content, and it is not modifying the original data, I see no problem. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Mailing list archives busticated
On Sun, Apr 20, 2014 at 8:29 PM, Ken Hornstein wrote: I just wanted everyone to know that right now the mailing list archives are broken, and it's my fault. Nice of you to take the blame, but the real blame is the brain dead parsing code in mhonarc, which appears I never really tested. Why the problem was never discovered before is beyond me (likely since attribute parts are rarely used in the wild). I've already been in communication with Earl Hood (the author of MHonArc) who confirmed the issue, and he's developing a fix right now. I don't know when that fix will make it to the mailing list archives on savannah, though. The archives on mhonarc.org should be fixed soon, and you can still access the raw mbox file from the archives on savannah. I've updated the archiving software on mhonarc.org that contains a fix to the problem, so the nmh-workers (HTML) archive there should be updating again: http://www.mhonarc.org/archive/html/nmh-workers/. --ewh P.S. It appears the IETF archive on mhonarc.org was also affected since I saw the same error in the log for it as for nmh-workers. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Mailing list archives busticated
On Sun, Apr 20, 2014 at 9:35 PM, Ken Hornstein wrote: I don't look at the headers of every message I get, but I did check my mailbox for examples when I was writing the RFC 2231 parser. I have never seen an extended MIME parameter on a Content-Type header in the wild, but I do see them all of the time on Content-Disposition headers (when the filenames get really long). Wonder what MUAs are nice to do that? From what I get, at least from my coworkers that mostly use Outlook, parts are not used, even for very long filenames. At a message I just looked at, Outlook appears to wrap the value itself vs using parts. For example: Content-Disposition: attachment; filename= This is a really long filename that outlook just appears to wrap instead of breaking up into parts.txt Of course, I hate Outlook with the passion of a thousand suns. It does seems that the popular MUAs do not fully leverage all of MIME and are not good about following open standards. In my somewhat-organized test data I have been using, I did not have a sample that used attribute parts. Well, I have one now ;) --ewh P.S. MHonArc does check the content-disposition header, but for security reasons, mhonarc ignores it by default. A person can enable honoring the filename, but they better understand the risks when doing so. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] First release candidate of nmh 1.6 now available
On Tue, Apr 15, 2014 at 3:00 PM, Ken Hornstein wrote: I have mixed feelings about this; I think /bin/bash is wrong, but I thought that /bin/sh should actually work everywhere. I know perl is all over the place, but I thought /usr/bin/perl was pretty standard. What do others think? /bin/sh should be used for shell scripts, and any scripts should avoid anything that only Bash supports. As for perl, /usr/bin/perl is fairly standard if Perl is installed, so I see no problem leaving it that way. However, the following could be used if you want to make perl scripts more flexible: #!/usr/bin/env perl The only real downside to this is if scripts can be run as root. Using env method could be a potential vulnerability. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] post now asking for a password, even when it doesn't have to
On Mon, Apr 14, 2014 at 10:28 PM, Lyndon Nerenberg wrote: I think in 1.7 we need to deprecate the POP support. And in 1.8 deprecate the submission SASL support. -1 on deprecating SASL support. I use it. I use delegated on my LAN, where my local systems can submit mail to it using SASL, and it is configured to then submit messages to gmail server for transport. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] post now asking for a password, even when it doesn't have to
On Mon, Apr 14, 2014 at 11:14 PM, Lyndon Nerenberg wrote: -1 on deprecating SASL support. I use it. Out of curiosity, which mechs? What's this have to do with anime? :) If you mean operating systems, my router/relay system is an old linux box (pre RHEL release) running on a 15+ year old box. My other systems are CentOS 5. I mount my mail directory across systems and have nmh configured to post any messages to delegated, which subsequently is configured to connect to gmail server (over TLS). I setup delegated some time ago since it seemed to be the easiest method at the time to get submission of email over a TLS-based connection. IIRC, at that time, I updated some of the SASL code so things like the what-now command 'whom' would work. I know I can get things better setup, but I get no pleasure with sysadmin tasks anymore, so I try to go with something that is the least amount of effort. I should not have to F with MTAs and other things in order to get an MUA to submit mail. Here is relevant entries in my .mh_profile (identifying information edited to protect the guilty): push: -unique -sasl -saslmech LOGIN -user USER -server local.example.com -port send: -verbose -sasl -saslmech LOGIN -user USER -server local.example.com -port whom: -check -sasl -saslmech LOGIN -user USER -server local.example.com -port I can configure delegatd to not require SASL login to access, but I wanted some simple access control so any one else I might let connect to my LAN cannot trivially submit email through my gmail account. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] warning when attaching rfc822 message
On Sun, Apr 13, 2014 at 7:55 PM, Lyndon Nerenberg wrote: Either you upgrade the top-level encoding, or you downgrade the encoding of the encapsulated message/rfc822. Correct, with the former likely the preferred method unless you know that the transport/delivery systems has problems with 8bit encoding. But something is nagging me that says the message/rfc822 cannot be binary, regardless. I will have to slog my way through the relevant RFCs again to satisfy my doubts. 7bit, 8bit, and binary are allowed for message/rfc822. No other encoding is allowed: No encoding other than 7bit, 8bit, or binary is permitted for the body of a message/rfc822 entity. The message header fields are always US-ASCII in any case, and data within the body can still be encoded, in which case the Content-Transfer-Encoding header field in the encapsulated message will reflect this. Non-US-ASCII text in the headers of an encapsulated message can be specified using the mechanisms described in RFC 2047. --- RFC2046, Section 5.2.1 --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context
On Wed, Feb 19, 2014 at 1:33 PM, Lyndon Nerenberg wrote: As for disk space, how much you use is a function of the types of email you receive and how much of a pack rat you are. Yep. Ages ago, if one had a ton of email, you may have issues of running out of inodes, but I do not think that is much of a problem anymore. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context
On Wed, Feb 19, 2014 at 1:44 PM, Paul Vixie wrote: i would. first, i'd adopt the messages-as-directories model norm gave, since it supports MIME, where our current model does not. by support i mean i want to use normal UNIX file access to work with my message store. there is no file-level access to attachments right now, which means i have to run mhstore to turn an opaque black-box attachment into a UNIX file i can access. mhstore is highly impure by MH's overall design principles, even though i'm grateful to have it under the circumstances. I have mixed feelings about this. Personally, I want the original, raw email message left alone and always available. Extraction of attachments could still be done, but leave the original. This allows preexisting email to be reparsed to leverage newer capabilities of the MUA, or by other external systems (e.g. digital signature verification). A problem that exists is the definition of attachment; it is not clearly defined in email. Content-Disposition is supposed to indicate if something is an attachment, but attachment could be inferred if the MUA is unable to rendering the entity directly (at a given moment of time). So, would it be required to extract each MIME entity to a separate file, regardless of disposition since one cannot predict how the user may want to access them at the file-level? It would cause a lot of duplication of data. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Should I learn nmh or GNU mailutils?
On Thu, Feb 13, 2014 at 1:56 PM, otahler wrote: I knew already that Sylpheed/Claws Mail used the MH system, as they are sitting on top of it. But now I was bit suprised to hear that they are just a GUI, because I thought of them as much more than a GUI. Just out of curiosity: do Sylpheed/Claw Mail use the original MH programs as backend, or did they write their own implementation of MH? I used Sylpheed briefly years ago, and I was under the impression that is was the later. It recognized MH folders, but it did not leverage the underlying commands for it. Maybe things have changed since then. IIRC, I used Sylpheed at the time to deal with encrypted and signed mail, something MH/nmh does not support directly. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] extensions on tmp filenames?
On Mon, Feb 3, 2014 at 12:46 PM, Robert Elz wrote: No, and I wasn't arguing against using mkstemps() where it is available, just against using link() in preference to rename() - that one makes no sense. | mkstemps() first appeared in OpenBSD 2.4. Oh, OK, given all those systems, I guess it is about time for it to migrate to NetBSD as well (it isn't there yet.) Just a bit of history: The whole rename of the temp file was introduced by me so the temp file can have a proper suffix for cases when the data is provided to an external process since it is common for programs to use filename extension as how to process the data. I understood, at the time, that rename() was atomic and relatively safe. At the time, I only knew about mkstemp() [Notice there is no 's' at the end of the function], therefore, there was no system call to make a temporary file with a specific suffix. My older linux system I was using at the time when making edits to nmh (and still have operational) does not have the call. A later one I have running (CentOS 5) does have it, but there is no manpage! I had to grep the system header files just now to verify the later system had the call. The DoS scenario David mentions seems highly unlikely to occur and it does not concern me. But I am all in favor of using mkstemps() and I would have used it if it widely available at the time. If it is not available, mkstemp()/rename() should be the fallback. nmh should have an abstract function that allows the creation of a temp file with a suffix so it can hide the method used based on what the system supports. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] extensions on tmp filenames?
On Sun, Feb 2, 2014 at 4:43 PM, David Levine wrote: Documented where? SUSv3 calls out the behaviour explicitly, as inherited from the ISO C spec. Well, the SUSv2 spec says: If the link named by the new argument exists, it shall be removed and old renamed to new. In this case, a link named new shall remain visible to other processes throughout the renaming operation and refer either to the file referred to by new or old before the operation began. and that's what Linux still uses for its documentation. For which manpage. CentOS 5 system for rename(2): If newpath already exists it will be atomically replaced (subject to a few conditions; see ERRORS below), so that there is no point at which another process attempting to access newpath will find it missing. What you quote is not well written and is not clear on what really may happen. My understanding is that rename() is atomic and safe, hence I felt there was no real security risk when I included the operation years ago for suffix support. I know you tried to explain to me via private email why there was still a security risk, but I still do not understand it. If there is a risk, it would be due to old and/or faulty implementations of the underlying OS compared to the way a rename() operation is supposed to work. I know it may be all academic now, but the practice of renaming temp files into persistent files is a common practice, like to avoid symlink attacks. Rename() is atomic and should overwrite any existing file with the same name. If a process had the file open before it is overwritten due to rename(), that process will only have a handle to the old file and not the new one. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Default and selectable Content-Transfer-Encoding issues
On Fri, Jan 31, 2014 at 12:50 PM, Ken Hornstein wrote: Right now if the text parts contain any 8bit or long lines ( 76 characters) the content is forced as quoted-printable. Obviously with a default of 8bit, 8bit characters are fine. But should lines 76 be 8bit, or q-p? I'm unsure which one is right. Thoughts? IMO, it should be a configuration setting. Today, q-p is rarely needed and is kind of annoying (especially in older releases of nmh, or MH, where q-p was not handled at all in reply composition). It would be nice to specify 8bit as the default, even if long lines are present, and/or an option to specify at what line length q-p is triggered. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] x-unix-mode MIME parameter?
On Mon, Jan 13, 2014 at 9:17 PM, Jon Steinhart wrote: I've noticed that when you run attach with -attachformat 0, you get a x-unix-mode MIME parameter. My question is: why? Jon did it that way originally, I don't know why. I needed a different format, with a Content-Disposition. When I created that, I dropped the x-unix-mode. ... I'm embarassed to say that I don't remember why I did that. I think that it was because I looked at attachment headerss in emails that I received, maybe even some created by mhbuild, and they had it. Looks like an AppleMail thing, at least based on some simple searching on the Net. IMO, it is useless, and a security problem if MUAs honor the parameter when saving an attachment. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] De-MIMEing
On Mon, Jul 15, 2013 at 12:39 PM, Ronald F. Guilmette wrote: This all suits me and my preferences perfectly. The only problem is that I have only been able to figure out how to arrange for MH to invoke my little mtext filter/reformatter *only* for cases where I am doing a show operation. I really would like to get it invoked also in all cases whene I am doing repl. Can someone tell me or given me guidance on how to do that? I use the -editor option to repl when I want to convert MIME messages into a plain-text format suitable for composition (and nmh repl filters). The script I use is mha-mhedit. You can view the documentation at http://www.mhonarc.org/MHonArc/extras/mha-mhedit/mha-mhedit.html to see how I interface it into nmh. Hopefully it will help you in what you may need to do to modify your script. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] De-MIMEing
On Mon, Jul 15, 2013 at 2:28 PM, Ken Hornstein wrote: replyfilter gets hooked into mhl as part of step 2) above. replyfilter's magic is new functionality in mhl that allows the body component of a message (basically, the whole body as one big piece) to be processed via an external program. I wrote mha-mhedit a long time ago, so I am not sure the magic you mention was possible in earlier versions of nmh (and in MH itself). If it was, I was not aware of it, and took an approach that works based on the knowledge I had of MH/nmh at the time. The wrinkle here is that replyfilter only has access to the body of the message, due to complications with mhl; the extra MIME headers it needs are passed as command line arguments I definitely needed an approach that provide access to the entire mail message. I have nothing against mha-mhedit's approach; my motivation was to have a solution that could work with third-party programs; you can't easily use mha-mhedit with something like exmh, for example (or at least it wasn't obvious to me). Since I already had software that did MIME parsing and formatting, mha-mhedit was a way for me to leverage it in order to overcome the deficiencies in MH/nmh's repl capbilities. I've never used exmh, so I am not sure if mha-mhedit can be used with it. Unless someone already has mhonarc (or does not mind installing it), I think Ken's script is the way to go until nmh can natively handle formatting replies to MIME messages better. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Smart enough to use nmh
On Wed, Jun 26, 2013 at 4:11 PM, n...@dad.org wrote: After all, if a person is smart enough to use nmh, they're smart enough to figure out how to fix a header line, right? I hope and believe that a person does not have to be unusually smart to to use nmh. Maybe it is better to say: The type of person to use nmh is likely to be smart enough to know how to manually fix a header line. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] message-external/body and auto-fetching(?)
Checking the nmh source code (and the old MH source code), it seems to me that if I show a message, but redirect to a file, MH/nmh will try to auto-fetch a message-external/body part (e.g. anon FTP). Am I correct in my reading of the code? Or, is it the case that any message-external/body part will be ignored if output is not to a terminal? --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] message-external/body and auto-fetching(?)
On Fri, Feb 8, 2013 at 2:41 PM, Ken Hornstein wrote:
Checking the nmh source code (and the old MH source code), it seems
to me that if I show a message, but redirect to a file, MH/nmh will
try to auto-fetch a message-external/body part (e.g. anon FTP).
Am I correct in my reading of the code?
Hm. That code is a bit hairy; can you point to me why you think that?
After a quick look, I'm a bit confused :-/
Agree about the mess. And it appears I have things a bit confused.
It seems that if stdin is not a terminal, auto-fetching will be done,
so things may not be that bad.
Some details:
Looking at the 1.5 nmh code base, the file uip/mhparse.c has the
following in the openFTP() function:
2573 /*
2574 * Now, check the answer
2575 */
2576 if (!getanswer (buffer))
2577 return NOTOK;
Checking the getanswer() function (sbr/getanswer.c):
14 int
15 getanswer (char *prompt)
16 {
17 static int interactive = -1;
18
19 if (interactive 0)
20 interactive = isatty (fileno (stdin)) ? 1 : 0;
21
22 return (interactive ? gans (prompt, anoyes) : 1);
23 }
It appears if stdin is not a terminal, getanswer() will always return 1.
Not sure what happens if authentication is required, have not traced the
code that far, but for anon-ftp external-body, it seems the data will be
auto-fetched. I am guessing if authentication is required, the user's
.netrc will be consulted.
I figure something like the following on the command-line will cause
auto-fetching:
show /dev/null message.txt
I guess if a user does such a thing, they are willing to live with the
implications of auto-fetching. I am curious if anyone has ever done
this in practice, but it appears the nmh code base (and MH) allow for
it.
I wondering if back-in-the-day, something like the above could be
done for priming a shared cache on a shared system.
--ewh
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 78 column limit
On Wed, Dec 5, 2012 at 2:48 PM, norm wrote: I send text/plain with lines no longer than 72 and blank lines between paragraphs. That's what I had been doing for years. And I did get complaints. It is an exercise in futility to deal with MUAs that do not following the specifications. Text/plain should be rendered in fixed-width font and line breaks should be honored. Inferring paragraphs and reformatting should not be done. format=flowed was created to indicate when reformatting of text blocks could be done, but also stay friendly to non-flowed-aware MUAs. nmh is not friendly in generating format=flowed, you will have to do it in the editor you use. And even if you do, unsure if all MUAs support it, or the MUAs that regular folks use. The lack of following of standards even occurs at Google. GMail fails to format text/plain in a fixed-font. Pain in the ass when dealing with code snippets and other text where fixed-width is essential. For GMail, I have domain-specific CSS settings for Firefox so mail messages are rendered in a fixed-font (and to hide ads). --ewh P.S. I had a contract where I was required to use Outhouse...cough!... Outlook. At the time, I was able to dig around in the preferences and get Outlook to render text/plain correctly, and even doing quoting properly when I replied to an email. Therefore, the core problem may be with what the default settings of MUAs are. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] colorized/highlighted scan output?
On Sat, Nov 3, 2012 at 12:14 AM, Lyndon Nerenberg wrote: Pretty much every modern terminal (emulator) supports color, so more power to those that want to do add color to scan output. But is it worth the added code complexity? But that is not what the initial criticism was about, unless I veered off course as I have been not following this thread in depth. The basic idea of adding color as being silly is a wrong, IMO. Now, what you ask is valid, but that is based on a cost-benefit analysis. Adding color has benefits, but it may not be worth the maintenance costs. It would be nice if the format syntax could support non-ASCII character sequences without munging them since I think this will be useful beyond including ANSI escape sequences. If the whole color push motivates some to to make it happen, more power to them. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] somewhat OT: re procmail or ??
On Tue, Sep 11, 2012 at 2:10 PM, rader wrote: LOGABSTRACT=yes with procmail-3.22-17 (RHEL/SL) only gets me Subject and Folder. Is there a new version around I didn't find?? (I only glanced and saw 3.22 and a msg to the ML bounced.) You are right. You have the From line added by the delivery agent that includes delivery date and what appears to be the envelope sender, so it is not the From: value of the message itself. I think for anything else, you will need to write a recipe to call a script that can log whatever headers you want to a custom log file. I was thinking of patching procmail directly so LOGABSTRACT=yes logs Date/From/To/cc/Subject header lines. Kinda thinking other prehistoric creatures might also like that? Possibly, and likely the only convenient way if you want such information associated with the destination folder listed in the log. You can likely achieve a similar affect with recipies, but it would complicate your procmailrc. Looks like there is a users' list for procmail, that still gets some light traffic: http://mailman.rwth-aachen.de/mailman/listinfo/procmail Might want to ping it to see what others think. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Handling non-ASCII
On Mon, Apr 16, 2012 at 12:27 PM, Lyndon Nerenberg wrote: Updated Estimate: .3,141.00 Updated Estimate: ?3,141.00 Presumably there is a loud warning being printed to say ***danger corrupt message - unprintable characters replaced with '.' Such warnings can be easily overlooked depending on how the warning is issued. With that said, a warning should be printed that invalid character sequences were encountered. IMO, I prefer '?' or U+FFFD, since this is how other applications behave when receiving invalid character sequences. U+FFFD is the best if your output device support unicode, but '?' can be used if dealing with a non-unicode-aware devices. Side Note: In software I maintain, I provide the option to specify what the default character encoding is. The default is US-ASCII, but there are environments that use other default encodings in their email, even though such encodings are not MIME encoded. Unsure if nmh should provide something similar; and mh-profile setting maybe. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
On Mon, Mar 12, 2012 at 11:05 AM, Lyndon Nerenberg wrote: I would prefer to build these non-822 directives using a syntax that can't be confused with a valid 822 header. I suggest the format: metahead = . directive *(SP params) directive = LETTER *(LETTER / DIGIT / -) params = ; free-form text to the end of line In the new syntax the above example would be written as: From: b...@example.com Sender: gr...@example.com .mail-from grunt+autodsnhand...@example.com I thought the X- prefix was the standard for designating non-standard headers. Therefore, for nmh, something like X-nmh- could be the prefix to use for any nmh-based custom headers. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
On Tue, Feb 14, 2012 at 1:23 PM, Ken Hornstein wrote:
Okay ... so now that's been cleared up :-)
Do people like the idea of:
- A dedicated function %(localmbox)
- A pseudo component %{localmbox}
- Extra primitives to build the default local mailbox (%(myname), %(myhost)).
If you go with a pseudo component, I recommend using a well-defined
prefix for it to avoid any potential collisions with a real component.
For example: %{nmh-localmbox}
--ewh
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings spost
On Tue, Feb 7, 2012 at 11:29 AM, Lyndon Nerenberg wrote:
But do you really think that
should be the only resort when badly formed mail arrives? I'd prefer to
see what was intended by the sender.
Yes, I do :-( QP and Base64 (and MIME in general) have been around for
nearly two decades now. If the sender can't get it right, too bad. And
really, the only time I see that sort of cruft is from spamming software.
And it can be a security issue. The, be liberal in what you accept,
mantra is dangerous from a security perspective.
I have no problems with mhshow throwing an error. It is simple
to then show the message w/o MIME processing. I have a bash function
that I use in cases when I need to see a message without any MIME
processing, but with basic mhl processing so I do not have
see all the raw headers:
sh.m() {
show -noshowproc $* | mhl
}
--ewh
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] urls from mhpath, and message store abstraction layers.
On Mon, Feb 6, 2012 at 12:51 PM, Joel Uckelman wrote: If/when IMAP support is added in, mhpath will return imap URLs. If one is using the existing classic storage model, then local pathnames are returned. IMAP URLs aren't paths, at least not in the sense I take 'path' to have in 'mhpath'. Maybe we could add 'mhurl' to produce URLs (and file: URLs for local storage!) and leave mhpath producing paths? Tomato, tomahto. Path can have different meanings depending on your context, but if you want to be pedantic, maybe have a new program called mhloc to represent the location of an nmh resource. mhpath can then just be mhloc, but with a pre-configured setting that if the resource is to a local file, it provides a local pathname instead of a file: URL. Regardless, mhpath should not barf if the resource happens to be a non-local pathname. It will still return a URL for such resources. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] urls from mhpath, and message store abstraction layers.
Wrt to mhpath, I think it is getting over analyzed. All mhpath does is provide the *path* to an nmh resource, that's it. Issues like fetching or not fetching are out-of-scope. If/when IMAP support is added in, mhpath will return imap URLs. If one is using the existing classic storage model, then local pathnames are returned. So, for the following command: mhpath +inbox If using the classic storage model: /home/user/MHMail/inbox And if IMAP storage is used: imap://imap.example.com/inbox Any additional storage models would return URLs appropriate for that storage model. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Minimum autoconf version required to compile nmh
On Fri, Jan 13, 2012 at 8:24 AM, Ken Hornstein k...@pobox.com wrote: Apparently, CentOS 5.7 version of autoconf is older than what the nmh build process says is required. CentOS 5.7 provides autoconfig 2.59 but nmh is configured to require 2.61 and later. I just looked ... and autoconf 2.59 was released in 2003, autoconf 2.61 was released in 2006. Yikes, I think CentOS is a bit behind here :-) CentOS is just repackaged RHEL, so Redhat can be pretty far behind in the versions of tools. I always have a bit of a problem deciding about using a new autoconf feature or macro ... it's not easy to tell when something was added. I wish the autoconf manual told you the version when each feature was added. I checked the change log file. Not sure how robust the change log is for the autoconf project, but that may be the only place to see what was done. It did mention that the macro I did get an error for was added to 2.60. This will not be the first time I've had to download various tools and install from source due to the age of the versions that are pre-provided by a linux distro. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Minimum autoconf version required to compile nmh
I have not compiled from source in sometime, but want to try out the latest changes, but hit a snag with running autogen.sh. Apparently, CentOS 5.7 version of autoconf is older than what the nmh build process says is required. CentOS 5.7 provides autoconfig 2.59 but nmh is configured to require 2.61 and later. Before I go off to download and build the latest version of autoconf, what are the reasons that 2.61 is the minimal version? Searching the commit archives, looks like the autoconf version number was up'ed to 2.61 on Nov 19, 2010 (so it has definitely been some time since I've built from scratch): http://lists.nongnu.org/archive/html/nmh-commits/2010-11/msg4.html I guess this leads up to the follow-up question: What are the minimal requirements needed to build nmh from repository checkout? The docs/README.developers states the following: If you wish to change the `configure' script or its related files, you'll need to first install GNU m4, available from ftp://ftp.gnu.org/pub/gnu/m4/ and then GNU autoconf (ftp://ftp.gnu.org/pub/gnu/autoconf/). Nmh is currently using a minimum of autoconf 2.54. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Minimum autoconf version required to compile nmh
On Thu, Jan 12, 2012 at 11:02 PM, Earl Hood wrote: I have not compiled from source in sometime, but want to try out the latest changes, but hit a snag with running autogen.sh. Apparently, CentOS 5.7 version of autoconf is older than what the nmh build process says is required. CentOS 5.7 provides autoconfig 2.59 but nmh is configured to require 2.61 and later. [snip] It appears that the configure.ac is setup to where it needs macros only defined in 2.60 or later. I tried to edit the file to allow for 2.59, but got errors: configure.ac:764: error: possibly undefined macro: AC_STRUCT_DIRENT_D_TYPE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 Macro listed was added in autoconf 2.60. So it looks like 2.60 (or 2.61) is required and docs/README.developers needs updating. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Dealing with missing From: header during send.
On Tue, Jan 10, 2012 at 4:56 AM, Ralph Corderoy ra...@inputplus.co.uk wrote:
Hi Earl,
%(lit)%(formataddr %{reply-to}%?{from}%?{sender}%?{return-path}%)\
%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
%(match example1.com)From: e...@example1.com\n\
%?(match example2.com)From: eh...@example2.com\n\
%|From: e...@earlhood.com\n%\
Does this shed any light? match seems to work here.
$ c='%(lit)%(formataddr
%{reply-to}%?{from}%?{sender}%?{return-path}%)%(formataddr{to})%(formataddr{cc})%(formataddr(me))'
Yes, that works, but as I noted, when in a replcomps, further
attempts to access {to} and other components return empty
values.
--ewh
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Dealing with missing From: header during send.
On Tue, Jan 10, 2012 at 2:19 PM, Ken Hornstein k...@pobox.com wrote: Ow. Damn your eyes, Earl ... I now have a headache from staring at the damn mh-format code. I'm glad you decided to look at the code since I was not looking forward to it myself. But, on the upside ... I figured out the issue here. The problem is not technically with accessing the same component again. It's actually accessing the same _ADDRESS_ again via %(formataddr). Let me explain. There is a cache inside of replsbr.c of addresses that were seem by the %(formataddr) function; if you try to insert the same email address twice, it will silently stop you from doing so. This is obviously to prevent duplicate email addresses from appearing in To: and cc: lines. So what is happening to you is when you try to use the to component again to make the decision to construct your From: line, it doesn't get addded to the list because formataddr considers it a duplicate. I would assume that if I use %(lit) to clear the str buffer, it should clear the cache. So, possible solutions? - Have %(putaddr) clear out the address cache via a callback to replsbr.c. This is a behavior change, and could result in duplicate addresses appearing in a cc: line (for example). I do not like this. I would think %(lit) should clear the cache since it empty the str register. - Create a new mh-format function (perhaps %(clearaddr) ?) that explicitly clears out the address cache. This may be acceptable. I'm not sure if there are components files that depending on the caching, even after %(lit) is used. The first one is easy, but might have unintended consequences. Agreed. The second is more complicated, but not terrible and is arguably more correct. Thoughts? My question is: If the str buffer is zeroed, or set, via %(lit), should the cache be automatically cleared? --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Dealing with missing From: header during send.
On Mon, Jan 9, 2012 at 12:39 PM, Paul Fox wrote: (i just checked, and realized that i'd be affected -- i have scripts that sometimes munge the draft to create a From: header based on current folder, and i see by the way i wrote them that there's an assumption that there's no such header by default.) Why not have a check in send/post that if the From: header is missing, it reports an error and aborts the operation? I think this will likely be needed regardless since anyone could delete out any pre-defined From: header in the draft before send/post receives it. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Dealing with missing From: header during send.
On Mon, Jan 9, 2012 at 9:05 PM, Ken Hornstein wrote:
I do the same thing as you, and I would like the same thing. There are
technical issues (you don't normally have access to the identity you received
the message at when repl gets it), but we could at least make it work
better than we do now.
It seems it should be doable via mh-format expressions, but
either I do not fully understand the engine's behavior or
it has some serious bugs.
It seems I am unable to access a component more than once
in some cases. When I do, the second time, I get nothing.
Here is something that I tried for replcomps (I've added
special lines to highlight the expressions of interest):
%(lit)%(formataddr %{reply-to}%?{from}%?{sender}%?{return-path}%)\
%(nonnull)%(void(width))%(putaddr To: )\n%\
%(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
%(nonnull)%(void(width))%(putaddr cc: )\n%\
%{fcc}Fcc: %{fcc}\n%\
- CODE-OF-INTEREST ---
%(lit)%(formataddr %{reply-to}%?{from}%?{sender}%?{return-path}%)\
%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
%(match example1.com)From: e...@example1.com\n\
%?(match example2.com)From: eh...@example2.com\n\
%|From: e...@earlhood.com\n%\
- /CODE-OF-INTEREST ---
%{subject}Subject: Re: %(putstr(trim{subject}))\n%\
%{message-id}In-reply-to: %{message-id}\n%\
%{message-id}References: %{references}%(void{references})%(trim)%(putstr) %
%(void{message-id})%(trim)%(putstr)\n%\
On %(lmonth{date}) %(mday{date}), %(year{date}) at \
%02(putnumf(hour{date})):%02(putnumf(min{date})), \
%{from}%(friendly{from})%|you% wrote:
In the CODE-OF-INTEREST, I try to gather all the addresses
in the original message into the string register so I
can then do a match against for a given domain so I can
output a different From:.
The problem is that my match checks always fail, even though
that I know the To: of the message being replied to has
example1.com in it.
Adding the following before or after match block, I do NOT
get an XXX: header printed:
%(nonnull)%(putaddr XXX: )\n\%\
If I do not do the nonnull check, repl hangs.
If I put my CODE-OF-INTEREST at the top of replcomps,
then setting of the To: in the repl draft does not work.
Maybe I do not fully get mh-format expressions, but this
behavior is odd. I would figure that references to
message components are immutable.
As an aside, it would be nice if named registers (i.e variables)
were supported. Maybe it is time to come up with a replacement
for mh-format.
--ewh
P.S. I am running a local dev build based on nmh 1.3, so I
do not know if the new nmh 1.4 includes any changes to
mh-format.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] #ifdef UCI
On Thu, Jan 5, 2012 at 10:55 AM, Ken Hornstein k...@pobox.com wrote: I've noticed that there are a number of places that are #ifdef UCI. They turn on various random things (like, if you have a file called .signature in your home directory, it will use it as the signature entry in your context). You would have had to turn this code on by hand, and I doubt anyone has used it in a long time. Anyone care if I nuke it? Unsure if folks at UCI still use/depend on such behavior. I believe UCI is using nmh now, but I'm not sure if they are doing custom builds of it to enable such features. I'd be inclined to remove it, but if you want, I can try to reach an old contact at UCI to see what the status of MH/nmh usage is at UCI. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Fri, Dec 9, 2011 at 5:25 PM, Jeffrey Honig j...@honig.net wrote: I have my fetchmail scripts ignore messages with a duplicate messageid (using a history of messageids I've received during the last 30 days or so) to avoid duplicate mail. Depends on what you mean by duplicate. From a mail archiving perspective, you can have multiple messages with same message ID, but can be considered different messages, even if the content is the same. Example: Mail that is sent to individuals and mailing list(s). Mailing lists typically add additional headers (e.g. List-*) and custom footers, so the message that is received by list subscribers is not identical to versions received directly from the original sender. It is probably too much to assume that everyone would not have duplicate copies of a message with the same messageid. Some people may have valid reasons for this. Archiving messages to mailing lists is a valid reason. And there may be messages w/o a message-id. This is the case for draft messages in nmh. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Fri, Dec 9, 2011 at 9:29 PM, Ken Hornstein k...@pobox.com wrote: I thought about breaking up the MIME parts, but I decided that the problem with that was that I believe there is value to still having the original message around. Just think of SMIME, PGP, DKIM, et.al. Preserving the original message is handy whenever one needs to (re)verify the message that are signed or encrypted. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] some indexing results
On Tue, Feb 8, 2011 at 1:26 PM, Paul Vixie vi...@isc.org wrote: format=flowed is now considered as the implicit default by some readers notably apple's Mail.app, because so many senders use the format without saying so in their mime headers. MH needs to adapt to current conditions. I have reservations about that. I have a pet peeve of MUAs not providing the proper headers, and I blame Microsoft for this historically bad behavior that has lead others to replicate this bad behavior. Before format=flowed existed, you had MUAs auto-wrapping text for text/plain message and rendering things in non-fixed width fonts. Hence, it is hard to say if what is being seen now is just a continuation of this, or if the underlying data is truly format=flowed, but not labeled as such. this probably means some heuristic where if the text looks like nonwrapped paragraphs then format=flowed is presumed, unless some CLI option overrides this. for example, a new show -autowrap / -noautowrap option defaulting to -noautowrap if !isatty(STDOUT_FILENO) and to -autowrap otherwise. I think any such heuristic should be disabled by default. nmh users are not your typical email user. I do not like software that formats messages in a matter that is different from what MIME headers indicate w/o my explicit knowledge. In the example you cite, I would have -noautowrap always be the default. Of course, if the MIME content-type header does state format=flowed, then auto-wrapping should occur as defined by the format=flowed spec. For cases when output is redirected to a non-tty device, you may need an option that allows one to specify the max column count so nmh would know what the wrap boundary is. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] SMTP/IMAP/POP Support
On Sun, Dec 5, 2010 at 9:34 PM, chad wrote: On Dec 5, 2010, at 6:52 PM, Earl Hood wrote: I do something like the following: fetchmail -m '/usr/bin/procmail -d %T' I used to do this, and have procmail do crude spam filtering. I eventually took it out of the loop because mail spool was not a reliable concept in my (relatively highly distributed) world. I'm curious if it gives any benefits today; I would expect machines without working mail spools to be even more common, but I haven't looked in forever. In your procmailrc you can specify any pathname to by the spool file if you are on a system that does not have one. Then just set default options to 'inc' in your .mh_profile to use whatever pathname you choose (and to truncate it since inc only auto-truncates the system mail spool file). --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Alternate list archive (was Re: [Nmh-workers] Understanding nmh)
On 12/1/10, Jon Steinhart wrote: Maybe I don't understand your proposed changes. Apologies if I get this wrong; I didn't save a copy of your original email and the archives are currently down. FYI, I've had a nmh list archive running for some time, as an alternative to what savannah provides: http://www.mhonarc.org/archive/html/nmh-workers/ The archive actually includes mail before nmh got hosted on savannah. Archive goes back to mid-1992. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Autoconf changes new feature
On Sun, Nov 21, 2010 at 12:37 PM, Ken Hornstein k...@pobox.com wrote: The way every other autoconf package works is that when it gets done, it results in a Makefile that sets CPPFLAGS and LDFLAGS appropriately, It sounds like what was done here was create a situation where you have to say: export CPPFLAGS=yadda explor LDFLAGS=yadda make to build it. And that won't fly for distros that have automated build machinery. I agree, that would not work for distros with automated build machinery. I'm not familiar with how the various distros automate their build processes, but the general statement that requiring the setting of envvars to configure a build cannot be automated, is hogwash. The more accurate statement is more likely the following: Requiring the pre-setting of envvars before building a package is something existing distro build systems are not tailored to support. However, I do wondering about the robustness of build systems that do not support setting envvars as part of the build configuration. BTW, at least in bash, you can do: CPPLAGS=yadda LDFLAGS=yadda make I've forgotten how many time I've set envvars this way for a single program I needed to execute w/o affecting my current environment. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC2047 section 5 and other MIME issues for the new scan
On Sun, Nov 14, 2010 at 11:45 AM, Jon Steinhart j...@fourwinds.com wrote: My preference is to say that we'll treat any =?...?= as an encoded word wherever it appears and that we'll decode it. It appears that the authors of RFC2047 expect that everything will be parsed into tokens and examined before looking for encoded words. You right. RFC 822 defined the basic tokenization rules, and MIME attempts to stay compatibile with that. I.e. You have a system that knows how to due RFC 822 tokenization, and then that token data can be passed to the MIME-aware layer. Here is a relevant note from RFC 2047: IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's by an RFC 822 parser. As a consequence, unencoded white space characters (such as SPACE and HTAB) are FORBIDDEN within an 'encoded-word'. For example, the character sequence =?iso-8859-1?q?this is some text?= would be parsed as four 'atom's, rather than as a single 'atom' (by an RFC 822 parser) or 'encoded-word' (by a parser which understands 'encoded-words'). The correct way to encode the string this is some text is to encode the SPACE characters as well, e.g. =?iso-8859-1?q?this=20is=20some=20text?= I think many mail implementations today probably do not work that way, mainly due to ignorance of the developers. Although not related to this topic, an example of this ignorance is the syntax adopted in DKIM headers. As for space between encoded word, such space should be collapsed. I.e. Two adjacent encoded words should be concatenated together after decoding, with no space between them. Note, it is a mistake to blindly assume that all sequences of =?...?= should be decoded, which has lead to some erroneous uses by some software. For example, using =?...?= inside parameter values vs using RFC 2184 (now RFC 2123). My current plan for the new scan code is to: 1. Read a header field name. 2. Read a header field body if the header field is used by the format, unfolding folded lines in the process. 3. Look for encoded words and decode them creating a UTF-8 version of the header field body. I've never really dived into MH/nmh parsing code. Is there any attempt to perform RFC 822 based tokenization before duing any other processing? Decoding of encoded words should only be done in specific contexts. Look at Section 5 of RFC 2047 the contexts that encoded words are allowed. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] character sets and localization
On Sat, Nov 13, 2010 at 11:50 AM, Jon Steinhart j...@fourwinds.com wrote:
Look at the $LANG environment variable, that's probably a good start on most
systems. The various LC_ environment variables if you want to do more
localization work.
That's the way it is on my Linux system but that doesn't make it standard.
C program to print out current preferred character encoding:
#include stdio.h
#include locale.h
#include langinfo.h
int main()
{
setlocale(LC_ALL, );
printf(%s\n, nl_langinfo(CODESET));
return 0;
}
--ewh
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] extending nmh for smtps support?
On Fri, Nov 12, 2010 at 8:08 PM, heym...@bellsouth.net wrote: The question that still out there is whether or not nmh should support smtps. If so, I'm more than willing to go back into the code and work on it. Would this be of interest? What kind of schedule are we looking at for nmh 1.4 (so I can gauge my time/commitment)? I think it would be nice to have native support for SMTP over TLS, but there is some effort in doing it. I looked at seeing what it would take, but I think some reworking of some of the I/O code would be required to provide a decent enough abstraction so alternate I/O transports can be used. However, I did find a workable solution since I wanted to use Gmails servers for sending outgoing mail. See http://earlhood.blogspot.com/2010/01/how-to-posting-to-gmail-servers-with.html for more details. I figure what I did can be used for Yahoo's mail servers. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] MIME questions, and followup to my earlier email
On Fri, Nov 12, 2010 at 9:50 PM, Jon Steinhart wrote: I haven't paid attention to mail standards in a long time. Is RFC 2231 a happening thing? Do we need to go through the trouble of supporting it? I have support for 2184 (which 2231 updates) in my OSS Perl program, but mainly when dealing with attachment data where is seems to be of most practical use. I think several MUAs support it, but unsure about the ones used by most people (e.g. Outlook). I've seen the use of non-ASCII encoding defined in RFC 2047 inside of parameter values, which is not valid, but is likely that MUAs are supporting such abuse due to developers misunderstanding the MIME RFCs. I do not recommend nmh even try to deal with such data. IMO, if there is motivation to provide more robust MIME handling in nmh, I think it would be a mistake to not support 2231. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Fixing decoding of quoted messages in replies
On Fri, Nov 5, 2010 at 4:48 PM, markus schnalke mei...@marmaro.de wrote: So send should: * check for non-ASCII characters * when present: pick an encoding (first usable one from a user-configurable list like us-ascii,iso-8859-1,utf-8) * encode body and headers as per MIME, adding MIME headers to match Just one quick thought: What about signed and encrypted messages? Where and how would this be done and would it interfere? During send. I.e. Have an option for send to support signing/encrypted. It is only at the send stage that you know a message will not be further modified by the user. With the current motivation by some to do work on nmh, supporting SMIME/PGP should be considered. If some of the mail parsing and MIME handling is improved, adding such support may become easier. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] MH 6.8.4 source code
On Thu, Nov 4, 2010 at 9:37 PM, Simon Burge sim...@netbsd.org wrote: Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: Do any of you have a pristine 6.8.4 source distribution lying around, or know of a current online archive? It'll take me weeks to figure out which set of archives my copy is in. Worse, the FTP server at UCI barfs when you try to cd into pub/mh :-( The first google hit for mh-6.8.4.tar looks valid. It also appears there is SourceForge project for preserving the old MH code base. Check out the list of files at: http://sourceforge.net/projects/rand-mh/files/ BTW, which UCI ftp did you (Lyndon) try to access? It looks like UCI systems are using nmh 1.1 now, so I'm not sure if the old MH is available anywhere, except maybe on some backup tapes. -ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: Diffs for replacing mktemp() usage
On Wed, Feb 3, 2010 at 2:58 AM, Peter Maydell pmayd...@chiark.greenend.org.uk wrote: Earl Hood wrote: Even though no one has convinced me that my new functions still contain the race condition security problem, There was a URL in the old linked message I provided; the problem is in the presence of /tmp/ cleaners (which, yes, do exist even if there are problems with them). I missed the /tmp cleaners. Yes, that could be an issue if the cleaner happens to run just as you are running an nmh command and the cleaner is dumb to remove the file even if it is recent, and them some malicious user just happens to be trying to symlink you. I'd have to question the skills of the sys admin that set that up a cleaner that deleted files despite the modtime. My latest changes causes tmp files to be put in user's mail dir if no template is specified. Note, looking more at the code, many commands change the cwd to the user's mail dir. They then call the temp file routine (before my changes and after my changes since I wanted to minimize risk to functionality) so temp files are created in cwd. Therefore, for most commands, temp files were already being placed in the user's mail dir. Where /tmp was getting used were calls to m_tmpfil(). Those calls were replaced with m_mktemp(). In my latest post of m_mktemp.c, I changed the function so m_maildir() will be used instead of /tmp. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: Diffs for replacing mktemp() usage
On Wed, Feb 3, 2010 at 12:20 PM, Sean Kamath wrote: Frankly, people who run tmp cleaners that are that braindead probably deserve what they get. Are we to worry about braindead temp cleaners? I.e. I'm sure other apps would have problems with braindead cleaners, so should we waste resources dealing with a problem that is not worth addressing? Regardless, moving them to a configurable tmp location is not a bad idea -- but I don't want to hit my NFS mounted home dir every time I make a tmp file. So I'd make /var/tmp/user or /tmp/user and point to that. I'm unsure if real-time performance is super critical with nmh. If going with /var/tmp/user, you still do not completely avoid braindead cleaners since you are still working under the system tmp directory. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: Diffs for replacing mktemp() usage
On Wed, Feb 3, 2010 at 12:30 PM, valdis.kletni...@vt.edu wrote: If the calling code did not immediately use the temp file, the new functions close the descriptor returned from mkstemp(), but it does NOT delete the file. Since the file still exists, an external (different uid) process cannot create one in its place, so the race condition vulnerability does not exist. The file is just sitting there. Unfortunately, this is only true if the directory you're creating the file in isn't writable by other processes - in other words, doing this in /tmp isn't safe, Standard procedure is to have the sticky-bit set on the system temp directory, so any files created in it can only be deleted/accessed by the owner (or root). But, yes, there are probably some f'ed up configurations out there. but doing a 'umask 077; mkdir /tmp/$USER' and then creating /tmp/$USER/$TMPNAME is safe. Sticky bit on the directory helps too, but we probably should program defensively and get it right even if the sysadmin failed to do so. Agree with philosophy, but the directory method does complicate cleanup, which requires more work. A descision to be made is the work I have currently done worth rejecting because it fails to address all (less probable) cases, or accept it now for something better than what currently exists and then improve upon it later? Since it has been years that nmh has existing with temporary file problem with no one fixing (a couple have tried and realized the worked involved so backed out), I think if there is any improvement to the current code base, it is worth accepting. Otherwise, you're still open to a race condition - an attacker can just rename the file you created, and then stick another file or even a symlink in place of the old name: % ls -ld /tmp/foo drwxrwxrwx. 2 root root 4096 Feb 3 09:30 /tmp/foo If you own the box, fix it. If not, complain to the sys admin. All my boxes have /tmp permissions set correctly, and it seems to be that way for stock Linux distros. Unsure about other unices out there, but I do remember many years ago having to fix /tmp permissions on solaris systems. Note, as of now, my latest changes default to user's mail dir for temp files. I'm not concerned about NFS, unless, there is some programs in nmh that are using temp files for locking/semaphore purposes. I do not use rcvstore, and related programs, so maybe someone can chime in if these programs use lock files or not. I can look at the code later, but I would like input from those that use such programs. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: Diffs for replacing mktemp() usage
On February 3, 2010 at 15:23, valdis.kletni...@vt.edu wrote:
Given that the vast majority of nmh users are probably on laptops or
single-user desktop boxes rather than large central servers with untrusted
other users on them, and your code *is* an improvement, I think the best
thing to do is drop in your patches, leave a TO_DO comment block in there
about what's still needed, and we revisit it if it ever becomes an issue.
Okay.
I did make some more mods to m_mktemp.c to make things a bit more
secure and to support specifying the temporary directory via
envvars. See comments in code for more details.
/*
* m_mktemp.c -- Construct a temporary file.
*
* $Id: m_mktemp.c,v 1.4 2002/07/02 22:09:14 kenh Exp $
*
* This code is Copyright (c) 2010, by the authors of nmh. See the
* COPYRIGHT file in the root directory of the nmh distribution for
* complete copyright information.
*/
#include errno.h
#include h/mh.h
static char *get_temp_dir();
/* Create a temporary file. If pfx_in is null, the temporary file
* will be created in the temporary directory (more on that later).
* If pfx_in is not null, then the temporary file location will be
* defined by the value pfx_in.
*
* The file created will be at the pathname specified appended with
* 6 random (we hope :) characters.
*
* The return value will be the pathname to the file created.
*
* CAUTION: The return pointer references static data. If
* you need to modify, or save, the return string, make a copy of it
* first.
*
* When pfx_in is null, the temporary directory is determined as
* follows, in order:
*
*MHTMPDIR envvar
*TMPDIR envvar
*TMP envvar
*User's mail directory.
*
* NOTE: One will probably use m_mktemp2() instead of this function.
* For example, if you want to create a temp file in the defined
* temporary directory, but with a custom basename prefix, do
* something like the following:
*
*char *tmp_pathname = m_mktemp2(NULL, mypre, ...);
*/
char *
m_mktemp (
const char *pfx_in, /* Pathname prefix for temporary file. */
int *fd_ret, /* (return,optional) File descriptor to temp file. */
FILE **fp_ret /* (return,optional) FILE pointer to temp file. */
)
{
static char tmpfil[BUFSIZ];
int fd = -1;
int keep_open = 0;
mode_t oldmode = umask(077);
if (pfx_in == NULL) {
snprintf(tmpfil, sizeof(tmpfil), %s/nmhXX, get_temp_dir());
} else {
snprintf(tmpfil, sizeof(tmpfil), %sXX, pfx_in);
}
fd = mkstemp(tmpfil);
if (fd 0) {
umask(oldmode);
return NULL;
}
if (fd_ret != NULL) {
*fd_ret = fd;
keep_open = 1;
}
if (fp_ret != NULL) {
FILE *fp = fdopen(fd, w+);
if (fp == NULL) {
int olderr = errno;
unlink(tmpfil);
close(fd);
errno = olderr;
umask(oldmode);
return NULL;
}
*fp_ret = fp;
keep_open = 1;
}
if (!keep_open) {
close(fd);
}
umask(oldmode);
return tmpfil;
}
/* This version allows one to specify the directory the temp file should
* by created based on a given pathname. Although m_mktemp() technically
* supports this, this version is when the directory is defined by
* a separate variable from the prefix, eliminating the caller from having
* to do string manipulation to generate the desired. pathname prefix.
*
* The pfx_in parameter specifies a basename prefix for the file. If dir_in
* is NULL, then the defined temporary directory (see comments to m_mktemp()
* above) is used to create the temp file.
*/
char *
m_mktemp2 (
const char *dir_in, /* Directory to place temp file. */
const char *pfx_in, /* Basename prefix for temp file. */
int *fd_ret, /* (return,optional) File descriptor to temp file. */
FILE **fp_ret /* (return,optional) FILE pointer to temp file. */
)
{
static char buffer[BUFSIZ];
char *cp;
if (dir_in == NULL) {
if (pfx_in == NULL) {
return m_mktemp(NULL, fd_ret, fp_ret);
}
snprintf(buffer, sizeof(buffer), %s/%s, get_temp_dir(), pfx_in);
return m_mktemp(buffer, fd_ret, fp_ret);
}
if ((cp = r1bindex ((char *)dir_in, '/')) == dir_in) {
/* No directory component */
return m_mktemp(pfx_in, fd_ret, fp_ret);
}
int n = (int)(cp-dir_in-1); /* Length of dir component */
snprintf(buffer, sizeof(buffer), %.*s%s, n, dir_in, pfx_in);
return m_mktemp(buffer, fd_ret, fp_ret);
}
static char *
get_temp_dir()
{
// Ignore envvars if we are setuid
if ((getuid()==geteuid()) (getgid()==getegid())) {
char *tmpdir = NULL;
tmpdir = getenv(MHTMPDIR);
if (tmpdir != NULL *tmpdir != '\0') return tmpdir;
tmpdir = getenv(TMPDIR);
if (tmpdir != NULL *tmpdir != '\0') return tmpdir;
tmpdir = getenv(TMP);
if (tmpdir !=
Re: [Nmh-workers] Re: Diffs for replacing mktemp() usage
On Wed, Feb 3, 2010 at 5:59 PM, Sean Kamath wrote: My real point was that it should be configurable, which you've done. Slightly odd to make it an env variable than an nmh setting in .mh_profile, but whatever. It's easy to add .mh_profile check, but not all commands read the profile (e.g. post). Do not know the reasons. In these cases, any tmpdir setting in them will not be used, making envvars the only reliable method for specifying tmpdir location. Therefore, I'm reluctant to add support for it since it may cause confusion by a user when the setting is not getting used. Does anyone know if `post' is the only program that does consult the .mh_profile? --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: Diffs for replacing mktemp() usage
On Wed, Feb 3, 2010 at 8:06 PM, Chad Brown yand...@mit.edu wrote: I don't know that anyone cares, but POSIX says ``TMPDIR'': Recent commit uses the following, in order: *MHTMPDIR envvar *TMPDIR envvar *TMP envvar *User's mail directory. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Diffs for replacing mktemp() usage
Attached are the changes I have currently done in my development
environment. The changes also include minor mods to deal
with may be uninitialized warnings from gcc.
I added a new file, sbr/m_mktemp.c, to include the new functions for
replacing m_scratch() and m_tmpfil().
The goal was to minimize the amount of re-coding, so the new functions
attempt to provide the basic capabilities of the older functions,
but using mkstemp() under the hood vs mktemp(). It seems the much
code has a heavy reliance on being able to access the actual pathnames
of temporary files vs just having an open handle to it.
Index: h/prototypes.h
===
RCS file: /cvsroot/nmh/nmh/h/prototypes.h,v
retrieving revision 1.26
diff -u -r1.26 prototypes.h
--- h/prototypes.h 16 Jan 2009 02:28:54 - 1.26
+++ h/prototypes.h 2 Feb 2010 19:36:04 -
@@ -81,6 +81,8 @@
int m_putenv (char *, char *);
char *m_scratch (char *, char *);
char *m_tmpfil (char *);
+char *m_mktemp(const char *, int *, FILE **);
+char *m_mktemp2(const char *, const char *, int *, FILE **);
void m_unknown(FILE *);
int makedir (char *);
char *nmh_getpass(const char *);
Index: sbr/Makefile.in
===
RCS file: /cvsroot/nmh/nmh/sbr/Makefile.in,v
retrieving revision 1.28
diff -u -r1.28 Makefile.in
--- sbr/Makefile.in 17 Jan 2009 16:47:30 - 1.28
+++ sbr/Makefile.in 2 Feb 2010 19:36:04 -
@@ -78,7 +78,7 @@
seq_setprev.c seq_setunseen.c showfile.c signals.c \
smatch.c snprintb.c ssequal.c strcasecmp.c \
strindex.c trimcpy.c uprf.c vfgets.c fmt_def.c \
- m_msgdef.c mf.c utils.c
+ m_msgdef.c mf.c utils.c m_mktemp.c
# source for compatibility functions
COMPAT = memmove.c snprintf.c strdup.c strerror.c
Index: sbr/fmt_rfc2047.c
===
RCS file: /cvsroot/nmh/nmh/sbr/fmt_rfc2047.c,v
retrieving revision 1.9
diff -u -r1.9 fmt_rfc2047.c
--- sbr/fmt_rfc2047.c 9 Mar 2006 19:51:13 - 1.9
+++ sbr/fmt_rfc2047.c 2 Feb 2010 19:36:05 -
@@ -71,7 +71,7 @@
int whitespace = 0;/* how much whitespace between
encodings? */
#ifdef HAVE_ICONV
int use_iconv = 0; /* are we converting encoding with iconv? */
-iconv_t cd;
+iconv_t cd = NULL;
int fromutf8 = 0;
char *saveq, *convbuf = NULL;
size_t savedstlen;
Index: sbr/fmt_scan.c
===
RCS file: /cvsroot/nmh/nmh/sbr/fmt_scan.c,v
retrieving revision 1.25
diff -u -r1.25 fmt_scan.c
--- sbr/fmt_scan.c 5 Apr 2008 18:41:37 - 1.25
+++ sbr/fmt_scan.c 2 Feb 2010 19:36:05 -
@@ -297,7 +297,7 @@
{
char *cp, *ep;
unsigned char *sp;
-char *savestr;
+char *savestr = NULL;
unsigned char *str = NULL;
char buffer[BUFSIZ], buffer2[BUFSIZ];
int i, c, ljust, n;
Index: sbr/getarguments.c
===
RCS file: /cvsroot/nmh/nmh/sbr/getarguments.c,v
retrieving revision 1.3
diff -u -r1.3 getarguments.c
--- sbr/getarguments.c 2 Jan 2006 03:17:42 - 1.3
+++ sbr/getarguments.c 2 Feb 2010 19:36:05 -
@@ -15,7 +15,7 @@
char **
getarguments (char *invo_name, int argc, char **argv, int check_context)
{
-char *cp, **ap, **bp, **arguments;
+char *cp = NULL, **ap = NULL, **bp = NULL, **arguments = NULL;
int n = 0;
/*
@@ -35,7 +35,7 @@
bp = arguments;
/* Copy any arguments from profile/context */
-if (n 0) {
+if (ap != NULL n 0) {
while (*ap)
*bp++ = *ap++;
}
Index: sbr/pidwait.c
===
RCS file: /cvsroot/nmh/nmh/sbr/pidwait.c,v
retrieving revision 1.6
diff -u -r1.6 pidwait.c
--- sbr/pidwait.c 11 Apr 2008 14:12:55 - 1.6
+++ sbr/pidwait.c 2 Feb 2010 19:36:05 -
@@ -22,7 +22,7 @@
pidwait (pid_t id, int sigsok)
{
pid_t pid;
-SIGNAL_HANDLER istat, qstat;
+SIGNAL_HANDLER istat = NULL, qstat = NULL;
#ifdef HAVE_UNION_WAIT
union wait status;
Index: uip/annosbr.c
===
RCS file: /cvsroot/nmh/nmh/uip/annosbr.c,v
retrieving revision 1.9
diff -u -r1.9 annosbr.c
--- uip/annosbr.c 5 Apr 2008 18:41:38 - 1.9
+++ uip/annosbr.c 2 Feb 2010 19:36:06 -
@@ -179,20 +179,15 @@
FILE *tmp;
intc; /* current character */
intcount; /* header field (annotation) counter */
-char *field; /* buffer for header field */
-intfield_size; /* size of field buffer */
-FILE *fp;/* file pointer made from locked file
descriptor */
+char *field =
Re: [Nmh-workers] Diffs for replacing mktemp() usage
On February 2, 2010 at 22:26, Peter Maydell wrote: Yes, this is why it's difficult to fix :-). Unfortunately, if you use mkstemp() but still allow the rest of the code to reopen the temporary file by name, you've shut the linker up but not completely closed the security hole. See http://www.mail-archive.com/nmh-workers@nongnu.org/msg01380.html So I would vote against (the tempfile related parts of) this patch. I do not think the problem applies here. With mkstemp(), the file is actually created at the time, so no race condition. If you look at the new functions, if no fd and no FILE return is requested, I only close the file. I do NOT unlink it. There are parts of the code where the file sits there before it is opened, but in that case, it is actually re-opening an existing file vs creating a new file. The only way the file becomes a vulnerability is of the sys admin has misconfigured the tmp directory to allow anyone to clobber anyone elses file. As for temporary files under ~/Mail, some operations in the code do that since the files end up being renamed. It is possible to modify the new functions I've added to default to the user's mail directory for creating temporary files vs /tmp. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Diffs for replacing mktemp() usage
On February 2, 2010 at 15:45, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: Having an MH-private namespace for scratch files is certainly the way to go here. These aren't 'temp files' in the traditional sense, and none of the usual APIs suit the task at hand. Actually, we have complete control of where temporary files go. mkstemp() does not impose any location of where temp files go. Now tmpfile() probably utilizes the system temporary directory since there is no ability to provide a template for it. tempnam() will use the system temp dir if its first argument is NULL. Wrt nmh, there are some operations where the temporary file must go in the operating location. For example, when the temporary file gets renamed. I can modify the new functions I implemented to use m_maildir() as the default location instead of /tmp when no template is provided. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Re: Diffs for replacing mktemp() usage
On February 2, 2010 at 13:40, Earl Hood wrote:
Attached are the changes I have currently done in my development
environment. The changes also include minor mods to deal
with may be uninitialized warnings from gcc.
Found a problem with mhparse.c with the changes I did. Temporary files
can be left around when show mime messages. The reason is the code
takes the temp pathname and appends a suffix to it based on mime type
(if a suffix is defined), then it uses that pathname, causing the
existing (waiting) temp file to be left.
I made changes to mhparse.c so if a suffix is to be appended,
it will rename the existing, waiting temporary file vs creating
a new file (which exposes nmh to the race problem).
Included is the diff of mhparse.c against CVS HEAD.
Index: uip/mhparse.c
===
RCS file: /cvsroot/nmh/nmh/uip/mhparse.c,v
retrieving revision 1.21
diff -u -r1.21 mhparse.c
--- uip/mhparse.c 14 Aug 2008 06:19:08 - 1.21
+++ uip/mhparse.c 3 Feb 2010 05:19:42 -
@@ -204,12 +204,14 @@
* Check if file is actually standard input
*/
if ((is_stdin = !(strcmp (file, - {
- file = add (m_tmpfil (invo_name), NULL);
- if ((fp = fopen (file, w+)) == NULL) {
- advise (file, unable to fopen for writing and reading);
- return NULL;
- }
+char *tfile = m_mktemp2(NULL, invo_name, NULL, fp);
+if (tfile == NULL) {
+advise(mhparse, unable to create temporary file);
+return NULL;
+}
+ file = add (tfile, NULL);
chmod (file, 0600);
+
while (fgets (buffer, sizeof(buffer), stdin))
fputs (buffer, fp);
fflush (fp);
@@ -1764,7 +1766,7 @@
}
if (*file == NULL) {
- ce-ce_file = add (m_scratch (, tmp), NULL);
+ ce-ce_file = add (m_mktemp(tmp, NULL, NULL), NULL);
ce-ce_unlink = 1;
} else {
ce-ce_file = add (*file, NULL);
@@ -1781,8 +1783,21 @@
ci-ci_type);
cp = context_find (buffer);
}
-if (cp != NULL *cp != '\0')
-ce-ce_file = add (cp, ce-ce_file);
+if (cp != NULL *cp != '\0') {
+if (ce-ce_unlink) {
+// Temporary file already exists, so we rename to
+// version with extension.
+char *file_org = strdup(ce-ce_file);
+ce-ce_file = add (cp, ce-ce_file);
+if (rename(file_org, ce-ce_file)) {
+adios (ce-ce_file, unable to rename %s to , file_org);
+}
+free(file_org);
+
+} else {
+ce-ce_file = add (cp, ce-ce_file);
+}
+}
if ((ce-ce_fp = fopen (ce-ce_file, w+)) == NULL) {
content_error (ce-ce_file, ct, unable to fopen for reading/writing);
@@ -1972,7 +1987,7 @@
}
if (*file == NULL) {
- ce-ce_file = add (m_scratch (, tmp), NULL);
+ ce-ce_file = add (m_mktemp(tmp, NULL, NULL), NULL);
ce-ce_unlink = 1;
} else {
ce-ce_file = add (*file, NULL);
@@ -1989,8 +2004,21 @@
ci-ci_type);
cp = context_find (buffer);
}
-if (cp != NULL *cp != '\0')
-ce-ce_file = add (cp, ce-ce_file);
+if (cp != NULL *cp != '\0') {
+if (ce-ce_unlink) {
+// Temporary file already exists, so we rename to
+// version with extension.
+char *file_org = strdup(ce-ce_file);
+ce-ce_file = add (cp, ce-ce_file);
+if (rename(file_org, ce-ce_file)) {
+adios (ce-ce_file, unable to rename %s to , file_org);
+}
+free(file_org);
+
+} else {
+ce-ce_file = add (cp, ce-ce_file);
+}
+}
if ((ce-ce_fp = fopen (ce-ce_file, w+)) == NULL) {
content_error (ce-ce_file, ct, unable to fopen for reading/writing);
@@ -2177,7 +2205,7 @@
}
if (*file == NULL) {
- ce-ce_file = add (m_scratch (, tmp), NULL);
+ ce-ce_file = add (m_mktemp(tmp, NULL, NULL), NULL);
ce-ce_unlink = 1;
} else {
ce-ce_file = add (*file, NULL);
@@ -2194,8 +,21 @@
ci-ci_type);
cp = context_find (buffer);
}
-if (cp != NULL *cp != '\0')
-ce-ce_file = add (cp, ce-ce_file);
+if (cp != NULL *cp != '\0') {
+if (ce-ce_unlink) {
+// Temporary file already exists, so we rename to
+// version with extension.
+char *file_org = strdup(ce-ce_file);
+ce-ce_file = add (cp, ce-ce_file);
+if (rename(file_org, ce-ce_file)) {
+adios (ce-ce_file, unable to rename %s to , file_org);
+}
+free(file_org);
+
+} else {
+ce-ce_file = add (cp, ce-ce_file);
+}
+}
if ((ce-ce_fp = fopen (ce-ce_file, w+)) == NULL) {
content_error (ce-ce_file, ct, unable to fopen for reading/writing);
@@ -2545,7
Re: [Nmh-workers] Alternative method for supporting TLS and latest patch set
On February 1, 2010 at 22:06, Ken Hornstein wrote: I looked over your patches; I say commit 'em (I'd personally prefer that nmh had inline TLS support,... I agree, but the changes are also applicable for any non-TLS mail server that requires SASL. The horse has definitely been pounded to death. Maybe some day nmh will have direct support for it. I may look at it again in the future. BTW, I'm working on removing all uses of mktemp from the code and trying to clean-up annoying warnings from gcc when compiling code. Hopefully, I do not break anything. I'll try things it out for awhile to see if anything breaks, but I do not use all the features of nmh, so some changes will not really get tested. I've taken the approach of creating new functions that use mkstemp() and replacing all calles to m_scratch() and m_tmpfil() with the new functions. I'm unsure what the policy is for how stable the trunk is supposed to be, so I hesitant to check in what I have done. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Why doesn't post consult .mh_profile?
I find it annoying that I have to replicate command-line options for 'send', 'push', and 'whom' because post does not consult the .mh_profile file. For example, if you use sasl, I have to specify the same set of sasl arguments multiple times: push: -unique -sasl -saslmech LOGIN -user user -server example.com -port 2000 send: -verbose -sasl -saslmech LOGIN -user user -server example.com -port 2000 whom: -check -sasl -saslmech LOGIN -user user -server example.com -port 2000 It would be nice to only specify them once, mainly to the program that actually uses them: post: -sasl -saslmech LOGIN -user user -server example.com -port 2000 So the other entries can be kept simple: push: -unique send: -verbose whom: -check --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Success in submitting mail to a secure MTA (was Re: should nmh be an MTA or an MUA?)
On January 30, 2010 at 10:49, Lyndon Nerenberg wrote: Not sure how it worked since SASL support is not available when using sendmail as your mts delivery method. I.e. If the SMTP server requires user/pass authentication, sendmail-based deliver will not work. Sendmail has had SASL support for years. The version shipped with your OS might not have it compiled in, but it's there. I meant, sendmail delivery mode within MH. I.e. When the mts: option is set to sendmail vs smtp. In this case, nmh will call (fork/exec) the sendmail program (as specified by the 'sendmail:' option in the mts.conf) to post an email message (or check addresses when in -whom mode). nmh invokes sendmail in -bs mode, allowing it to communicate with the program (via stdin/stdout) using SMTP commands. Under this usage model, nmh's SASL support does not exist. And if using the openssl command to create a basic SSL pipe to the SMTP server, SASL support is needed. IMO, this allows greater flexibiltiy since dumb proxy connections can be established w/o being burdened by SMTP and SASL operations. It is similiar to rsync and the --rsh option, allowing one to establish remote connections using alternative protocls (ssh) w/o burdening rsync with such details. Maybe nmh should have an option to allow one to specify an external process for establishing the remote connection to the SMTP server. This way, mts mode can be set to smtp, but one can specify an external program to establish the end-points of the communication. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: should nmh be an MTA or an MUA?
On January 29, 2010 at 23:01, Ken Hornstein wrote: If your interest is to only exchange messages with other nmh users, then I guess you won't care ... but I would suggest that if nmh doesn't evolve, at some point there won't be any other nmh users. I agree. For years, I have used a separate program I wrote to deal with replying to MIME messages: http://www.mhonarc.org/MHonArc/extras/mha-mhedit/mha-mhedit.html It ain't the most efficient thing, but it works. And I have found over time that I've had to use it more frequently, even for basic messages. Ideally nmh should do what mha-mhedit basicly does. Of course, the other big hurdle nmh has is that it is command-line oriented, limiting those who may choose to use it to more advanced computer users that appreciate the power and flexibilty the command-line can provide. I think the capabilities and maintenance of GUI front-ends to nmh may be the determining factor if nmh stays around or fades away. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: should nmh be an MTA or an MUA?
On January 29, 2010 at 11:36, markus schnalke wrote: What exactly do you mean with ``users''? If you mean people that are no programmers, then I agree. If you mean us, then I don't. I consider non-programmers. If not, nmh will just be a nitch MUA, and probably over time, die a slow death. Not too many appreciate the power that nmh offers, but the command-line (for whatever reasons) gets a bad rap. Humans are visual creatues, so GUIs have a natural allure, even if poorly written. Now I see why we do not understand each other: - For you, nmh is a system that provides everything for emailing. - For me it is an MUA. From your POV, nmh *should* include an MTA, a fetch program, and so forth. From my POV, it should *not*. No, you project thoughts onto me to help support your argument. I see nmh as an MUA. Period. See a separate post that quotes RFC(s) on what the definition of a MUA is and what its role is in the mail system: http://www.mhonarc.org/archive/html/nmh-workers/2010-01/msg00078.html I, and others, are only talking about the retrieval of mail from an MTA and the submission of mail to a MSA or MTA. Maybe you need to revisit the definitions and roles of the various parts of the mail system. Submission of mail is an MUA function. If in the usage context of nmh, the achieval of that submission happens to be achieved via some third party program, it is STILL an MUA function, not an MTA function. I say: Write software for yourselfs, because otherwise you won't do it well anyway. This statement seems to contradict the anti-NIH perspective. I want to motivate to forget the difference between library and program. Separate instead of integrate. I understand this, basic abstraction principles. Where you are off is what the functional role of an MUA is. You are attributing MUA-based functions as MTA functions. Is the burden more on the the application developer-side or the end-user side? I tend to lean toward the developer-side to make end-user life easier. Good point. Thus, I much favor good end-user howtos (this is different to documentation). But I feel good design to be the higher goal. Both are needed. As of now, there is neither for some of things that nmh users request. And if there is information, it is scattered somewhere on the Net instead of in the nmh documentation. Does anyone still maintain the MH FAQ? --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
On January 28, 2010 at 11:04, markus schnalke wrote: Use a simple forwarding MTA (like nullmailer or ssmtp) instead. Has anyone got either of these programs to work with nmh? If so, can they share their configuration? IIRC, ssmtp is a command-line replacement of sendmail vs running as a daemon. MH/nmh communicate with sendmail via the -bs option, something ssmtp does not support I believe. I have not looked at nullmailer. First I've heard of it. Does it support -bs mode of sendmail? Can it run as a daemon and accept SMTP connections directly? --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: should nmh be an MTA or an MUA?
On January 28, 2010 at 10:39, Ken Hornstein wrote: Fetching mail is also the job of a different tool. So, just so we're clear ... you want to remove the existing support for POP in inc as well? I agree with Ken. At some point, nmh must be able to read (incorporate) mail to do its job. I.e. It must fetch the mail from something, somehow. At the time MH was written, local spool files was all there is, but things change. POP came to be a legitimate (standard) delivery model, so MH was adopted to support it. From my understanding of the history of MH development, the intent was to have it be in-sync with Internet mail standards. Remember, MH, early on, provided MIME support before most MUAs did, and while attended UCI years ago, there was still some active development with MH promoting this perspective. Nmh should try to stay in-sync with Internet mail standards, not relying on external tools to support features MUAs are expected to support directly. I think mail retrieval and submission are core MUA functions, and an MUA should support the standard mechanisms for doing so. --ewh P.S. Ideally, IMAP would be supported, but I think IMAP exposes initial design decisions within MH that do not work well with the IMAP model. Personally, I could care less about IMAP support since I've never needed to use IMAP, but I understand others desire to want to support it w/o having to give up nmh. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Verizon DSL block
On January 22, 2010 at 11:02, Stewart W Wilson wrote: I tried the patch given by Valdis Kletnieks http://lists.gnu.org/archive/html/nmh-workers/2004-08/msg8.html I changed smtp.c (in nmh1.3) as he said to do. But it didn't work. The no servers available error didn't occur, but this time send just hung. Is authentication required? Just changing the port does little to deter spam since spammers can adapt. I would assume that the port change also comes with the requirement that you must specify your username and password. I do not know if nmh supports any authentication capabilities. It probably should since authentication is coming more common and service providers. At this time, my provider does not require it. Also, the smtp port should be configurable vs hardcoded. Using a proxy model with programs like ssmtp or msmtp may be possible. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Verizon DSL block
On January 22, 2010 at 16:26, Ken Hornstein wrote: The port 25 block is pretty much standard for large ISPs today; it's to prevent spammers from using massive networks of compromised PCs to deliver spam. Changing ports is useless unless authentication is required. If deterring spammers is the primary goal, then ISPs can just require authentication for customers over the standard SMTP port. Changing to the submission port provides no benefit unless authentication is required since spammers just tweek things to use the submission port to send spam. However, even with authentication, if a system is zombied, probably would not take much for authentication credentials to be stolen by the malware and used for sending out spam. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] preventing change of current folder with rcvstore?
On August 18, 2009 at 11:33, bergman wrote: I use procmail to automatically file incoming mail into different folders, using rcvstore. This works very well, but rcvstore changes the default folder . According the the rcvstore manpage, the context should not be affected: CONTEXT No context changes will be attempted, with the exception of sequence manipulation. Do not know offhand if this behavior has changed over time or not. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] MH and Google contacts
On July 4, 2009 at 10:43, Bill Wohler wrote: I'd like to start synchronizing my MH aliases with the contacts in my phone and Google contacts. Has anyone given any thought to this? Looks like Google has a CSV format that can import/export, so some little scripting can be done to map MH aliases into Google contacts and vice-versa. To determine what the CSV format is, just do an export of your Google contacts to it to figure it out. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: big thanks
On Sun, Jan 25, 2009 at 9:17 AM, Joel Uckelman uckel...@nomic.net wrote: I think the cut-off is more likely to be gen-Xers than baby-boomers. MH used to be the default MUA at MIT until ~2000, which is where I picked it up. I left UCI in '93, and of course, it was the default MUA on many systems. Not sure if it is still used at UCI, but I would bet some of the old-time profs may still use it. I still use it now. I have yet to find a GUI-based MUA that allows me to be as efficient an MH/nmh. It would be nice if nmh supported SMTP/TLS. I think it is more in danger of becoming obsolete in not staying up-to-date with later secure mail transit protocols and other mail standards versus the age of its users. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: enhancement to mhfinddup
On Mon, Sep 15, 2008 at 11:12 PM, Bill Wohler [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I started to use Bill Wohler's mhfinddup script[1] to delete the duplicates It may not matter, but attached is a Perl script I wrote some time ago to check for message duplicates. Probably similiar to Bill's, but have not looked at Bill's to determine similarities or differences. Run perldoc on file to read documentation or execute with -man option. --ewh msgdups Description: Binary data ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What Happened to mha-mhedit?
On October 1, 2007 at 11:10, Martin McCormick wrote: I moved my mail base of operations from one system to another and installed the latest version of mhonarc, still using the configuration files I had used on the slightly older system. I started to reply to a mime message and got the error stating that /usr/local/bin/mha-mhedit was missing. It had been part of the source tree for the FreeBSD port of mhonarc but it seems to have vanished. mha-mhedit is not part nmh, so this not the appropriate forum for your question. I noticed you sent a post to the mhonarc-users list, so I will respond there. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: ADMINISTRIVIA: Change to mailing list policy
On March 6, 2006 at 18:44, Bill Wohler wrote: Earl Hood [EMAIL PROTECTED] writes: I recommend discard. Spammers are known to use originating addresses of regular people, so you can potentially be the cause of receiving more spam due to mis-directed bounces. Unfortunately, this is worse because legitimate posters don't get a notification that their message didn't get through. An unfortunate side-effect, but probably something we must live with. Bounce noise can get bad and generate anger among those that receive bounce messages that they never sent. It is more common now for mailing lists to be limited to subscribers only. I'm not sure how Mailman creates bounce messages, but bounces can open a door for exploitation by spammers. More information about the lists and how to contact nmh developers could be included on the nmh web pages. Directing them to savannah's support request form is an option non-subscribers can use. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] ADMINISTRIVIA: Change to mailing list policy
On March 7, 2006 at 15:12, Ralph Corderoy wrote: I recommend discard. Spammers are known to use originating addresses of regular people, so you can potentially be the cause of receiving more spam due to mis-directed bounces. But Mailman is generating a `your message is pending approval because you're not subscribed' email at the moment, isn't it? So changing policy from `hold' to `bounce' won't be creating more emails back to the OP, just altering what kind they get. Mailman has a discard option so the list admin is not bothered with any mail. Of course, non-members do not get any notification that there message was discarded. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Wishlist item - beefing up slocal pattern matching
On December 26, 2005 at 16:10, Igor Sobrado wrote: Indeed, I missed that important matter. Certainly nmh should follow standards as nicely as possible. It does not make sense violating a RFC only because a product (in this case, the email filtering service provided by Postini) does. I was not aware about the case-insensitive behaviour not only on the header field names but also in the field contents. Case sensitivity of field contents is dependent upon the field itself. Although it appears that there is the intent of field values to be case insensitive in the core mail RFCs, this does not reflect modern reality. For example, the List-* header fields can have different meanings if case was ignored. I.e. List-* fields can have URLs, and URLs are not case-insensitive (excluding any domain portion or other component that is explicity specified as being case-insensitive). BTW, there may also be security concerns involved with ignoring case, depending on the application involved. Therefore, some applications may be case sensitive (header field names should be excluded) to prevent security vulnerabilities. In addition to the example noted, a problem exists with non-ASCII encoded data. Ideally, support for decoding non-ASCII encoded data would exist before a pattern is applied (normalization to UTF-8, or other Unicode encoding format, would be done). Due to complexity of case conversion for many languages, case-sensitive matching would be much easier here from an implementation perspective. However, software does exist that deals with such complexities (e.g. Perl). Ignoring non-ASCII encoded data could also be a security concern depending on the nature of the application. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Displaying/Replying to HTML emails
On November 23, 2004 at 17:39, Arun Bhalla wrote: In addition, like many of you, I'm sure, I have to read and respond to emails containing text/html parts. Reading isn't so bad since I just pipe it through lynx in my .mh_profile, although sometimes I'd rather have it default to text/plain (see above). But replying can be nasty, especially if there's only a text/html part (seemingly common from Hotmail users) and no text/plain part. I'd rather not have any non-text parts in the reply body if there's a text/plain part; if the text/html part is the only text part, I'd rather have it stripped of tags. I might argue that some nmh utility should do all of that for me, but if someone can recommend some scripts and .mh_profile configurations, I certainly wouldn't mind. The problem is even worse with multipart/mixed messages that include attachments. What I did was hack up a script, http://www.mhonarc.org/MHonArc/extras/mha-mhedit/mha-mhedit.html, to deal with situations when I need to deal with multipart and/or HTML messages. --ewh ___ Nmh-workers mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Nmh status - working on nmh
On September 16, 2004 at 17:20, Harald Geyer wrote: Is there any sort of wish list for nmh development? There are a number of issues in the TODO list. I don't know who maintains it though. I feel most important is better mime support ... and of course cleaning up the code. Savannah supports defining Tasks for a project. It may be worth using to track various TODO items. --ewh ___ Nmh-workers mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Vulnerability advisory for MIME software
The NISCC has posted an advisory mentioning security problems with MIME-aware software. The advisories were also posted by Corsaire to the VulnWatch mailing list. The advisory mentions that various vendors used a MIME test suite from NISCC to evaluate their products. Unfortunately, NISCC does not make such test suite publicly available (a personal response to my inquiry is attached below), but projects like mozilla apparently have evaluated their software with the test suite. My bet is that no one involved with nmh has seen the test suite to see if nmh is open to any of the problems the advisory discusses (note, the advisory is vague on specific vulnerabilities). I maintain software package that does MIME processing, so I can pursue obtaining the test suite for my package and see if it is worth having nmh have access to the test also; assuming there is interest among nmh developers and users. ---BeginMessage--- Hi, NISCC has a policy of only releasing test tools to recognized developers of the protocol in questions. If you meet this requirement we use a non-legally binding framework agreement as a measure of sharing sensitive information. Please supply further details. Best Regards Cameron From: Earl Hood [EMAIL PROTECTED]> Date: 14 September 2004 07:34:11 BST To: [EMAIL PROTECTED] Subject: Re: NISCC Vulnerability Advisory 380375/MIME Reply-To: Earl Hood [EMAIL PROTECTED]> NISCC, Your advisory mentions the existence of a MIME test suite, which some vendors have used to evaluate their products. Unfortunately, your advisory does not provide a link of the test suite so authors of MIME-aware software are able to evaluate their products. Is your test suite publicly available? Thanks, --ewh -- Earl Hood, [EMAIL PROTECTED]> Web: http://www.earlhood.com/> PGP Public Key: http://www.earlhood.com/gpgpubkey.txt> Cameron Team Leader, Management Disclosure NISCC Vulnerability Team tel:+44-20-7821-1330 x4520 mb: +44-7795 390286 fax:+44-20-7821-1686 mailto:[EMAIL PROTECTED] http://www.niscc.gov.uk/ National Infrastructure Security Coordination Centre (NISCC): Protecting the Critical National Infrastructure from Electronic Attack This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. This email message has been swept for computer viruses. Cameron Team Leader, Management Disclosure NISCC Vulnerability Team tel:+44-20-7821-1330 x4520 mb: +44-7795 390286 fax:+44-20-7821-1686 mailto:[EMAIL PROTECTED] http://www.niscc.gov.uk/ National Infrastructure Security Coordination Centre (NISCC): Protecting the Critical National Infrastructure from Electronic Attack This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. This email message has been swept for computer viruses. ---End Message--- ___ Nmh-workers mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Alternative list archive at mhonarc.org
I've set up an alternative list archive at http://www.mhonarc.org/archive/html/nmh-workers/. There is currently no direct link to the archive on the All Lists page. Another user on the list stated he has list message back to 1992, so when I am able to get a copy, I can import them into the archives. Currently, email addresses or obfsucated to protect against harvesters. If this is not an issue for anyone, I can regen the archives to show addresses and allow direct download of raw mail messages. --ewh ___ Nmh-workers mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/nmh-workers
