Re: [Nmh-workers] masquerade settings & spost
>The problem is where the mention of spost appears in the FAQ. >The complete question and answer are below. spost is in the last >recommendation, #7. For the purpose of answering this question, does #7 >do anything that "mts: sendmail" does not? When I asked about spost earlier, there was one legitimate use I saw for it. Someone used it to send messages through a custom program that encrypted all of their outgoing email; that would be hard to do with regular post unless they implemented all of "sendmail -bs". It sounded like everyone else that used spost had put it in their .mh_profile a decade ago to fix some long-forgotten problem. I'm with David; mention of it should be removed from the FAQ, and people should be directed to use the sendmail MTA. Optionally we could tell people about the -server option to send when using the SMTP MTA. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Bill wrote: > David Levine writes: > > >> >I've had this in my .mh_profile almost since I started using nmh: > >> > > >> > postproc: /usr/libexec/nmh/spost > >> > >> Wow, how did you ever know to use it? > > > > That's in the FAQ. Should be removed, I think. > > There seemed to be some legitimate reasons for its use. Even I used > spost for some time. There's been few questions that I've completely > removed. I agree. I'm not arguing for removal of spost from nmh. The problem is where the mention of spost appears in the FAQ. The complete question and answer are below. spost is in the last recommendation, #7. For the purpose of answering this question, does #7 do anything that "mts: sendmail" does not? The explanation for #7 sounds like the user wants to work around a server problem. If they're going to edit their config file, why not remove that server? If it's a transient problem, they wouldn't have to edit the config if they used the -server option to send. #5 should say "mts: smtp" and "mts: sendmail" instead of "mta: sendmail/smtp" and "mta: sendmail", respectively. #6 should be removed from this answer because the sendmail executable is not run when using SMTP. David Subject: 06.04 Fixing "post: problem initializing server; [BHST] no servers available" From: Peter Marvit , Eric Bracken Date: Tue, 1 Nov 1994 00:00:00 -0800 The error message itself is essentially correct. However, what this really means is: MH's post cannot connect to a running sendmail over an SMTP port (MH configured with SMTP and SENDMTS). The potential problems: 1. Your local sendmail daemon is dying or not running for some reason. 2. You use BIND and your local nameserver is not responding. Solution: Delete "/etc/resolv.conf." 3. Your $MHLIB/mts.conf (mtstailor) has its "servers:" pointing to a non-existent machine or a machine which is a) not reachable or b) not running the sendmail daemon. From: Bdale Garbee , Eric Bracken Date: Sun, 1 May 1994 00:00:00 -0800 4. The hostname localhost [127.0.0.1] is missing from /etc/hosts. Solution: add an entry for "localhost" to /etc/hosts or your DNS database or add the following to $MHLIB/mts.conf (mtstailor): servers: 127.0.0.1 \01localnet From: Larry Daffner Date: 3 Mar 1996 14:39:54 -0600 5. Your load average is so high that sendmail is refusing connections. Solution: Change your configuration from "mta: sendmail/smtp" to "mta: sendmail" so that a sendmail processes is spawned to deliver the message. This is a double-edged sword since the extra process only makes the load worse. From: Corbin Covault Date: Sun, 02 Sep 2001 02:13:42 -0400 6. Sendmail may not be located on the path that MH expects. Solution: Try specifying the path explicitly by adding a line to mts.conf thus: sendmail: /usr/sbin/sendmail or wherever your sendmail daemon executable lives. From: Neil W Rickert Date: 13 Apr 2001 18:47:43 -0500 7. You don't want to use an available server. Solution: Try postproc: /usr/local/lib/mh/spost in your MH profile (but check the path first). That should use command line sendmail. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
David Levine writes: >> >I've had this in my .mh_profile almost since I started using nmh: >> > >> > postproc: /usr/libexec/nmh/spost >> >> Wow, how did you ever know to use it? > > That's in the FAQ. Should be removed, I think. There seemed to be some legitimate reasons for its use. Even I used spost for some time. There's been few questions that I've completely removed. The way the FAQ works is that I put the most recent email at the top of a topic. If someone wants to contribute a concise response as to why one should not use spost, and perhaps alternate solutions to the problems posed in that question, I'd be delighted to add it. Since the nmh version has changed (dramatically), the FAQ is definitely due for an update! -- Bill Wohler aka http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On 2012-02-07 18:29, Lyndon Nerenberg wrote: > On 2012-02-07, at 7:37 AM, Oliver Kiddle wrote: > > > But do you really think that > > should be the only resort when badly formed mail arrives? I'd prefer to > > see what was intended by the sender. > > Yes, I do :-( QP and Base64 (and MIME in general) have been around for > nearly two decades now. If the sender can't get it right, too bad. And > really, the only time I see that sort of cruft is from spamming software. > > We have the far to usual case of maillists blindly tagging on their footer to base64 messages. Not spam, not an unexpected breaking, just stupid software at the source. -A ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Date:Tue, 07 Feb 2012 09:36:10 -0500 From:Ken Hornstein Message-ID: <201202071436.q17eaeal030...@hedwig.cmf.nrl.navy.mil> | - Code simplification. That's what removing support for turning off | draft_from is about For what it is worth, in case it was not obvious, I do not have draft_from (or anything) defined in my mts.conf masquerade setting. I know I have, in this day and age, a somewhat unusual environment, in that I control everything that relates to my mail system (MUA, MTA, DNS,...) and I make sure it all operates correctly. With that, essentially all of the MH defaults are correct. In general, I think that MH options (in the "how to process mail" sense anyway, as opposed to "make this compile on system X") are all set so that on a properly configured system, they don't need to be touched. They exist because it was known that there are many improperly configured systems, that MH installers don't often get to fix, and yet MH needs to work anyway. If you're planning on changing the default for an option, I think you really need to make sure that you're keeping things so MH operates properly (in all senses). And that includes keeping the header values all semantically correct as intended by the mail standards. | - Reasonable defaults. The discussion that has been hashed out over the | last month on this has resulted in the following consensus view: | | - All drafts have to have a From: line in them; if they don't, post will | reject them. | - The default components files will have From: lines in them. | - There will be a configurable hierarchy as to where the default From: | information will come from (see the mailing list archives). This here | is the part that is requiring the majority of new code. I don't object to any of that, I can't imagine a (private) components file without a From: field in it, and I think I see an advantage to always creating one, even when using the default components files, so the user can see what is going to be generated, rather than only finding out when the recipient of the e-mail wonders why it came from that unusual address. On the other hand, I personally don't think any of this is important enough to spend a lot of cycles on, this isn't an area where nmh is really deficient. | But ... based on what you're saying, nothing I'm proposing is going to | change how you use nmh. Well, except that post probably isn't going | to generate a Sender: header anymore You can't do that and remain compliant to the RFCs, it was that that I was trying to point out in my first message (the one with the two addresses in the From: header, which has been legal internet e-mail since forever). When there's only one address in the From: (most of the time) then according to the syntax, Sender: is optional, but to be semantically correct, Sender needs to be there when the From: header does not represent the person actually sending the e-mail (none of this has anything to do with forgery, that's only if the sender isn't authorised to send as the address used, and is irrelevant here). For this, we need (well, already have) a list of addresses that represent me, if the From: header is something different than me, a Sender header ought to be inserted. The envelope from (which can be different from both From: and Sender) needs to always be set to a value that will get e-mail bounces back to me (the person actually running send). Note: I'd actually prefer the determination of "me" for Sender generation purposes to be different to the one used by %(mymbox) as I actually prefer to keep Sender for many of my identities, even though that are "me" (stuff like postmaster, and hostmaster, and list-request). On the other hand, when I send from my academic address (the @coe.psu.ac.th) I used in the example with two addresses, I don't need a Sender added (and obviously not for my long term "normal" address as used in this message.) That is "don't need" as opposed to "don't want", if one is generated, then so be it, it s harmless. Similarly, for my other identities, for which I would prefer to make sure a Sender header is present, if it isn't, then that would not be a disaster. But when I send mail for my wife, and use use her e-mail address in the From: header, which I do occasionally, then I certainly do want/require a Sender header. And so does rfc5322: The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. The semantic intent of that (as well as the syntactic requirement that there must be a sender if the from field has more than one address, which comes a little earlier in the RFC) really needs to be maintained for MH to retain its status as one of the best mail syste
Re: [Nmh-workers] masquerade settings & spost
>On the other hand, I personally don't think any of this is important >enough to spend a lot of cycles on, this isn't an area where nmh is >really deficient. Well, I respectfully don't agree. You admit yourself that your setup is unusual; you control all of the components (including DNS) yourself. I would daresay that is EXTREMELY unusual across email users in this day and age; perhaps not MH/nmh users, but it's certainly becoming rarer and rarer. More specifically, the defaults don't work for me, today. >You can't do that and remain compliant to the RFCs, it was that that >I was trying to point out in my first message (the one with the two >addresses in the From: header, which has been legal internet e-mail >since forever). >[...] Here's my basic answer to all of this. As far as I can tell, it's nearly impossible for nmh to know what the "correct" value of Sender: out of the box (Lyndon has spoken to this more eloquently than I ever could). So I would posit it's your responsibility to know what the right value is. It looks like nmh will currently reject a draft with a Sender: field. I could be persuaded to remove that check and let you fill in the correct value. I could also be persuaded to require that if you have multiple addresses in the From: header that you _have_ to have a Sender: address. As for the envelope from ... well, no idea what the right answer is there. I think it has to take it from the draft (which could default to the Sender: address). I lack the energy for making a seperate knob for it, so it's going to be one or the other. >different to the one used by %(mymbox) as I actually prefer to keep >Sender for many of my identities, even though that are "me" (stuff like >postmaster, and hostmaster, and list-request). %(mymbox) actually checks Alternate-Mailboxes, so you can't really use it that way; that's why you need a new format function. >On the other hand, when >I send from my academic address (the @coe.psu.ac.th) I used in the >example with two addresses, I don't need a Sender added (and obviously >not for my long term "normal" address as used in this message.) That is >"don't need" as opposed to "don't want", if one is generated, then so >be it, it s harmless. Similarly, for my other identities, for which I >would prefer to make sure a Sender header is present, if it isn't, then >that would not be a disaster. But when I send mail for my wife, and use >use her e-mail address in the From: header, which I do occasionally, >then I certainly do want/require a Sender header. And so does rfc5322: Yeah, the problem here is I can't really think of a way for nmh to know that your "mailbox" is different than the From: header you're using, at least not in any way that would work sanely for everyone, or even a reasonable proportion of people (for example, it would never work for me based on the way I use nmh). > | Well, people have made what I consider reasonable arguments in terms > | of use cases for IMAP support in nmh. Of course when nmh has IMAP > | support (I'm an optimist!) it shouldn't affect you in any way. > >Initially, most probably not. I guess I'm a little afraid that it >is likely to become the most common use mode, leading to both people >failing to appreciate the advantages of being able to use all the unix >tools, on all e-mail, all the time (even when not connected to the >network, like in a plane - though that restriction seems to gradually >being lifted, at a cost...) and to eventually, the worth of features >being judged by whether or not they work wit e-mail on an imap server >instead of locally (we've already seen some of that with annotate). Can't really help you there; it's clear that IMAP is the way the world is going in terms of email. That ship has sailed, found a new country, and has declared their independence. Let me put it another way: you want better MIME support. You have a lack of time/energy/desire to do it yourself. So you want someone else to do it. But ... those other people (like me) have other priorities. If you want better MIME support, this is what you're going to have to put up with. It's either that or nmh doesn't change at all. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
> >I've had this in my .mh_profile almost since I started using nmh: > > > > postproc: /usr/libexec/nmh/spost > > Wow, how did you ever know to use it? That's in the FAQ. Should be removed, I think. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On Mon, 06 Feb 2012 22:02:15 EST, Ken Hornstein writes: yes! please either keep it, or improve post by giving it a switch that allows it to submit mail to an mta/msp program directly. >>> >>>E ... you know about the sendmail mts, right? >> >>i do indeed - but post always talks smtp, even with mts: sendmail. >> >>i need something that submits to a program on stdin without any >>to-and-fro interaction - which is precisely what spost does. > >Really? I'm curious ... why? sorry for the late response, but here it is: i'm using kuvert, a wrapper for outbound mail that gpg-signs/encrypts it automatically based on where the mail is going. (see http://snafu.priv.at/mystuff/kuvert/ if interested) that's my "sendmail:" entry in mts.conf, and the kuvert tool emulates/wraps sendmail in stdin mode (ie. sendmail or sendmail -t). i do this job at that particular point in the pipeline because i use all of exmh, mh-e (and occasionally raw nmh) in parallel and don't want to teach each of them independently what my crypto preferences are - and i *definitely* don't want two+ parties caching my key passphrases. as to living with post-doing-batched-smtp: of course i can hack up kuvert to support this, but i really really like the straightforward simplicity of non-interactive, one-shot submission of mails where smtp isn't involved (locally). >Enough people have said that they use it that it's not going >to get removed for 1.5; I'm just trying to understand what they need >from spost that post doesn't provide. that's fine, and in time i'm sure somebody will find the energy/time to contribute the code for an spost-like submission mode for post. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On 2012-02-07, at 10:13 AM, Joel Uckelman wrote: > What you're describing here is far beyond what I was intending; I only > want a seamless way to apply my eyeballs to these broken messages. I don't think it gets any more seamless than cat. I would have show (and anything else) print the full pathname to the message file upon error, and leave it to you how you want to deal with looking at it. Earl has already suggested some alternatives that provide at least minimal header processing, should you want that. But the job of the MH commands is to process *822-compliant messages. As soon as we're out of that realm, their work is done. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Thus spake Lyndon Nerenberg: > > all > > such nonconforming mail in the bin. That said, when I get mail from > > ConfMaster, it tends to be mail that I need to read, so I appreciate = > it > > when nmh can take a guess and perhaps show me some not-too-garbled = > text. > > (In this particular case, 'show' just barfs, sadly.) > > Can you define 'barf' in a bit more detail. And could you forward one = > of those messages to me (offline) as an attachment? Message forwarded. After displaying the headers, I get this from 'show': mhshow: don't know how to decode content (content text/plain in message 10) and it exits. It's not crashing, but I wouldn't mind if after getting this error message, it tried dumping the offending MIME part into less as a fallback. All I really want is a shot at looking at the contents without having to do anything special. > Any attempt to re-sync after a decoding error is a vector for security = > breaches. If I can fool your MIME parser, I can create what, upon = > visual inspection looks like a legit message, but when shovelled into = > your favourite external processing script, inserts a faked out MIME part = > that sends grandma porn to the DHS. > > The great thing about MH is that you can apply cat/less/vi to a = > malformed message and let your brain try to decipher what's going on, = > therefore there is no need to open yourself up to attack by trying to = > turn show into an AI engine. What you're describing here is far beyond what I was intending; I only want a seamless way to apply my eyeballs to these broken messages. -- J. ___ 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:46 AM, Joel Uckelman wrote: > My suggestion, then, is this: Could we both have some indication that > the input is bad, *and* have nmh make an attempt at interpreting it? -1 You can already invoke show to disable MIME processing, so when you encounter such a message, just do: show -noshowproc | less or, if you want headers to still be processed nicely: show -noshowproc | mhl You start increasing the risk of security vulnerabilities when "interpreting" malformed data. Any wrong interpretation could lead to an attacker compromising your system with a specially crafted message. At the most, nmh could fallback to just rendering the message through mhl if there is MIME error if you do not want to do one of the commands above yourself, but I think that is the most nmh should do. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On 2012-02-07, at 9:29 AM, Lyndon Nerenberg wrote: > being liberal about what you except Oh good lord, did I really write that?!? :-) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
> I would love to be able to prevail upon them to fix this or to dump all > such nonconforming mail in the bin. That said, when I get mail from > ConfMaster, it tends to be mail that I need to read, so I appreciate it > when nmh can take a guess and perhaps show me some not-too-garbled text. > (In this particular case, 'show' just barfs, sadly.) Can you define 'barf' in a bit more detail. And could you forward one of those messages to me (offline) as an attachment? > My suggestion, then, is this: Could we both have some indication that > the input is bad, *and* have nmh make an attempt at interpreting it? I > appreciate knowing when I have bad input; otherwise, I can't crusade > for internet hygiene. But I also appreciate being able to read > malformed, yet important messages. Certainly show(1) should not crap out when presented with garbage. But the best it can reasonable expect to do is terminate gracefully after printing an error message. Any attempt to re-sync after a decoding error is a vector for security breaches. If I can fool your MIME parser, I can create what, upon visual inspection looks like a legit message, but when shovelled into your favourite external processing script, inserts a faked out MIME part that sends grandma porn to the DHS. The great thing about MH is that you can apply cat/less/vi to a malformed message and let your brain try to decipher what's going on, therefore there is no need to open yourself up to attack by trying to turn show into an AI engine. --lyndon ___ 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] masquerade settings & spost
Thus spake Lyndon Nerenberg: > > On 2012-02-07, at 7:37 AM, Oliver Kiddle wrote: > > > But do you really think that > > should be the only resort when badly formed mail arrives? I'd prefer to > > see what was intended by the sender. > > Yes, I do :-( QP and Base64 (and MIME in general) have been around for nea= > rly two decades now. If the sender can't get it right, too bad. And reall= > y, the only time I see that sort of cruft is from spamming software. > > But ultimately, you cannot guess what the sender intended. Did they intend= > to send 8859? If so, why that exception character in the midst of what is = > otherwise valid QP? Does the encoder have a bug? It would seem unlikely i= > n this day and age. The alternatives are someone hand-editing the encoded = > message content =96 in which case I won't even try to guess what they meant= > - or the more likely scenario of someone trying to attack your M[STU]A by = > botching the MIME parser. And never rule out sunspots; cosmic ray memory b= > it flips *do* happen. > > Postel's maxim about being liberal about what you except meant "don't crash= > the IMP when someone sends buggy packets." It never meant "read the sende= > rs mind." Is anyone else here an academic who's had to use ConfMaster for submitting papers to a conference? If so, maybe you've had the same experience I have: ConfMaster sends out mail with the value "ENCODING_8BIT" for the Content-Transfer-Encoding header. I've pointed out to them repeatedy that this isn't a permissible value according to RFC1521, and that it makes their notification emails unreadable in some email clients---to no avail. I would love to be able to prevail upon them to fix this or to dump all such nonconforming mail in the bin. That said, when I get mail from ConfMaster, it tends to be mail that I need to read, so I appreciate it when nmh can take a guess and perhaps show me some not-too-garbled text. (In this particular case, 'show' just barfs, sadly.) My suggestion, then, is this: Could we both have some indication that the input is bad, *and* have nmh make an attempt at interpreting it? I appreciate knowing when I have bad input; otherwise, I can't crusade for internet hygiene. But I also appreciate being able to read malformed, yet important messages. -- J. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On 2012-02-07, at 7:37 AM, Oliver Kiddle wrote: > But do you really think that > should be the only resort when badly formed mail arrives? I'd prefer to > see what was intended by the sender. Yes, I do :-( QP and Base64 (and MIME in general) have been around for nearly two decades now. If the sender can't get it right, too bad. And really, the only time I see that sort of cruft is from spamming software. But ultimately, you cannot guess what the sender intended. Did they intend to send 8859? If so, why that exception character in the midst of what is otherwise valid QP? Does the encoder have a bug? It would seem unlikely in this day and age. The alternatives are someone hand-editing the encoded message content – in which case I won't even try to guess what they meant - or the more likely scenario of someone trying to attack your M[STU]A by botching the MIME parser. And never rule out sunspots; cosmic ray memory bit flips *do* happen. Postel's maxim about being liberal about what you except meant "don't crash the IMP when someone sends buggy packets." It never meant "read the senders mind." --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On 2/7/2012 3:37 PM, Oliver Kiddle wrote: > Lyndon Nerenberg wrote: >> Or you could use cat(1). > Well that's what I do do. > > It's great that MH makes that easy and there are various situations in > which I will go straight to the file. 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. i am +1 to this. but i exchange a lot of MIME with people all day long, in a way that shell level tools can't help me. so i've moved to IMAP and i've converted a small subset of my MH folders to "Maildir" format. what this means to me is that if i can't figure out what someone intended or i need to run grep, i have to fight like hell to figure out which file in the Maildir swamp contains the message that my mail reader isn't parsing correctly. until i can run 'emacs' on that file i don't really know what's going on. imagine my relief if i could run pick and mhpath, either on the same server where my imap server runs (if i want to see a local file system path name) or on my laptop (if i want to see an IMAP url and perhaps a local copy of the file.) using thunderbird helps me a tiny bit more than it hurts me, but it hurts quite a bit. i want my MH tools back. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Lyndon Nerenberg wrote: > On 2012-02-07, at 3:00 AM, Oliver Kiddle wrote: > > I'd prefer to just see the email. mhshow could have a -pedantic or -lint > > option. > > Or you could use cat(1). Well that's what I do do. It's great that MH makes that easy and there are various situations in which I will go straight to the file. 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. Oliver ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On 2/7/2012 2:36 PM, Ken Hornstein wrote: >> ... (nb: >> this is not to denigrate IMAP. For people whose needs it serves, it is >> just fine, it is just that those needs, and MH's requirements, aren't >> compatible.) > Well, people have made what I consider reasonable arguments in terms of > use cases for IMAP support in nmh. Of course when nmh has IMAP support > (I'm an optimist!) it shouldn't affect you in any way. indeed, if MH sprouts IMAP capabilities then they will be optional and should not affect users of normal MH tools or even the 'cat' command. noting: i disagree that the needs which beget IMAP are incompatible with MH's requirements. i need both, real bad. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>I don't understand that, I've used multiple identities, without any >particular difficulties, for a long time now (> 20 years), and MH (and >later nmh) just works as it is. That is, to say, in this area I see >no need for any changes, and consequently no need for any code to be >developed. Well, there are really two different things here that are sort of conflated. Let me seperate them out: - Code simplification. That's what removing support for turning off draft_from is about (I have to touch that code anyway, and making it simpler would help me out). The options for controlling draft_from just make the code hairier, and I'm not even sure it makes any sense given the changes coming. So far no one has made any reasonable argument why this code should stay; I'm open to hearing some reasons, so if you want to keep this selectable it's time to speak up. - Reasonable defaults. The discussion that has been hashed out over the last month on this has resulted in the following consensus view: - All drafts have to have a From: line in them; if they don't, post will reject them. - The default components files will have From: lines in them. - There will be a configurable hierarchy as to where the default From: information will come from (see the mailing list archives). This here is the part that is requiring the majority of new code. In my view, this part has been settled; if people had objections to this, they should have made them back when this was under discussion. As you point out, nmh has let you use multiple identities for a long time now. This isn't so much about that part (although, see below), but more about being able to do it in a more logical way. But ... based on what you're saying, nothing I'm proposing is going to change how you use nmh. Well, except that post probably isn't going to generate a Sender: header anymore (not sure about this part ... I was going to wait until I get in there to figure that out). But assuming you have draft_from turned on, you probably haven't been generating a Sender header anyway. >From what I can figure out, the thing people most want to add is some >magic to have nmh choose which identity it should use, rather than needing to >be told. Personally, that is exactly what I don't want - automation >like this gets addictive, and we start to assume it always works >correctly, and so don't bother to verify it every time - but in this >area, it is almost impossible to be perfect, that way can lead to >embarrassing mistakes. I respect your opinion, but as someone who's replcomps now selects the "right" email address to use in From: headers ... man, I can't go back now (I'm lucky in that the heuristic I use is relatively simple). And I'm not the only one who would make use of this feature. But of course you are still free to use nmh in the way you use it now. >And I absolutely understand that, and for whatever my opinion as to how >you should allocate that limited time is worth, and I understand that is >not much, I'd prefer you use it in the areas where it is clear that MH >does need work, of which the most obvious is MIME handling (particularly >for replies, the rest of it might be clunky, but kind of works). As we've discussed ... fixing THAT problem is not easy. It's being worked on (slowly), but it's going to be tough. >useless to me, and should be just as useless to any true MH user. (nb: >this is not to denigrate IMAP. For people whose needs it serves, it is >just fine, it is just that those needs, and MH's requirements, aren't >compatible.) Well, people have made what I consider reasonable arguments in terms of use cases for IMAP support in nmh. Of course when nmh has IMAP support (I'm an optimist!) it shouldn't affect you in any way. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On 2012-02-07, at 3:00 AM, Oliver Kiddle wrote: > I'd prefer to just see the email. mhshow could have a -pedantic or -lint > option. Or you could use cat(1). ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
To me, Ken's suggestions here sound good. In just about every installation of nmh I've ever had, the first thing I do is to set masquerdade: draft_from. (Currently, I have exim configured to choose an appropriate smarthost based on the From address. I have From: set in my draft as part of my prompter like zsh script.) Ken's suggestion of using mh-format to handle existing functionality like substituting an environment variable seems like the best approach because we can put something resembling the existing behaviour in the components file that will then work for people that just use nmh without configuring a From address. And most people will continue to set From to one of their various addresses using their existing mechanisms. On a system, where draft_from was not appropriate a system administrator ought to configure sendmail to reject e-mails with an incorrect domain. On the subject of spost, I would be happy to see it go. If someone has a better reason for needing it than because they configured postproc years ago for long forgotten reasons then fair enough. In that case, it'd be better if they can modify post so mts.conf can have an mts: value of pipe (or whatever) to use sendmail -t. It also might simplify things if post was split up into one programme for expanding aliases, applying filters, handing Bcc etc and another for actually submitting the e-mail. Robert Elz wrote: > One of the things MH always stood for was interpreting the mail standards > strictly, not just "anything that make other mailers happy" - and much of > the complexity is there to try as hard as possible to make that be true. This is fine aslong as you're talking about sending mail and what nmh produces. Unfortunately, this approach in nmh often gets in the way of nmh actually being useful. For example when reading some e-mails, I get: mhshow: invalid QUOTED-PRINTABLE encoding -- expecting hexidecimal-digit, but got char 0x74 I'd prefer to just see the email. mhshow could have a -pedantic or -lint option. Oliver ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Robert Elz writes: >If all you want from mh is "show/next/comp/repl/rmm" you might just as >well use thunderbird, or sylpheed, or even outlook express - they all >provide methods to read, delete, reply, ... to e-mail, and usually with >a user interface that is easier to master. Don't be so sure of that. Even just basic reading and replying is better in nmh than anything else I've found. In particular, replcomps is a wonderful thing. As for draft_from, I always have it turned on. It suits my needs perfectly. I have no need to turn it off, so removing the ability to do so wouldn't affect me personally. But nmh has a wide variety of users, and if we can continue to cater to those that do need to turn it off, I believe we should strive to do so (or if not, at least provide a way to achieve the same behaviour using other methods). >(nb: this is not to denigrate IMAP. For people whose needs it serves, >it is just fine, it is just that those needs, and MH's requirements, >aren't compatible.) I tend to agree somewhat. I have no problem with people wanting to add an IMAP backend to nmh. I guess I can see some situations in which it might be useful. But personally, it's not something I can see myself using. I want all of my data sat on my own machines where I have control of it, not on a remote server somewhere, and that includes email. So even were I to use IMAP, I'd be doing so as a POP replacement. I can vaguely see that I could use an IMAP server on one of my own servers, but I'm not seeing any advantages over just having my mail in my home directory as I currently do. I appreciate that others have different requirements to me, though. Tet ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Date:Tue, 07 Feb 2012 01:53:04 -0500 From:Ken Hornstein Message-ID: <201202070653.q176r4r9026...@hedwig.cmf.nrl.navy.mil> | Well, here's the problem ... it's easy for you to say that, isn't it? | I mean, you're not the one doing the coding. :-/ Believe me, I understand that, but ... | It's not that I disagree with the theory ... but it's running up | against the cold hard reality that a) we have people clamoring for | features like being able to select between different mail identities, I don't understand that, I've used multiple identities, without any particular difficulties, for a long time now (> 20 years), and MH (and later nmh) just works as it is. That is, to say, in this area I see no need for any changes, and consequently no need for any code to be developed. >From what I can figure out, the thing people most want to add is some magic to have nmh choose which identity it should use, rather than needing to be told. Personally, that is exactly what I don't want - automation like this gets addictive, and we start to assume it always works correctly, and so don't bother to verify it every time - but in this area, it is almost impossible to be perfect, that way can lead to embarrassing mistakes. So, I prefer to simply tell it every time, manually, which identity to use (or at least when I don't want my "normal" identity) so that I know it is picking the right one. For that, nmh as it exists (modulo any problems it might have selecting the Sender address when needed, which I was not aware of) is just fine, and I'd simply leave it alone. | and b) my development time is limited. And I absolutely understand that, and for whatever my opinion as to how you should allocate that limited time is worth, and I understand that is not much, I'd prefer you use it in the areas where it is clear that MH does need work, of which the most obvious is MIME handling (particularly for replies, the rest of it might be clunky, but kind of works). kre ps: not related to this topic, but the other that comes and goes from time to time - I believe that what makes MH special, and why most of us here grew to love it in the first place, is that all the mail is available for processing by the full set of unix tools - and without necessarily requiring use of mhpath (that is useful when I need to find the path for a particular message, but if I just want to sort messages by word count, I don't need that - unless I really need to make the method of finding where a folder lives highly portable, which for my local hacks, I don't). If all you want from mh is "show/next/comp/repl/rmm" you might just as well use thunderbird, or sylpheed, or even outlook express - they all provide methods to read, delete, reply, ... to e-mail, and usually with a user interface that is easier to master. The point of this postscript is that someone noted earlier that fetching e-mail from an IMAP server just reduces IMAP to POP - my point is that for nmh, that's exactly what we want (what I want anyway), and that having the e-mail on some inaccessible server is useless to me, and should be just as useless to any true MH user. (nb: this is not to denigrate IMAP. For people whose needs it serves, it is just fine, it is just that those needs, and MH's requirements, aren't compatible.) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>Please don't reduce nmh to being just another mailer in the "as long as >it works with outlook it is OK" camp that so many others have fallen >into. It must continue to be semantically, as well as syntactically, >correct. Even if the code to do that is not easy to make work, or >understand. Well, here's the problem ... it's easy for you to say that, isn't it? I mean, you're not the one doing the coding. :-/ (But hey, if you ARE willing to do the coding, I'm not going to stand in your way. In fact, that would be great.) It's not that I disagree with the theory ... but it's running up against the cold hard reality that a) we have people clamoring for features like being able to select between different mail identities, and b) my development time is limited. So ... we have to make some hard choices. And based on the previous discussions we've had over the past few weeks, I think that the choice has already been made. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>sorry. i was rambling. i'm only saying that it should be dropped, >because, a) it's a pretty new feature, so there are probably people >actively using it, and b) it's quite a useful feature -- on the fly >modification (albeit limited) of the From: address, in a way that caters >to the variable-recipient feature found in all major MTAs today. (i.e., >pgf+mh@... or pgf-mh@...) (Note: Paul meant "shouldn't be dropped" ...) While I think that's useful, I do wonder how many people use it. Hm, I guess it's really just a re-working of the old plussed_user option, and it used to check the USERPLUS variable. Looks like Dan Harkless updated that code ... over a decade ago. Okay, yeah, I guess that's new by nmh standards :-) > > Well, the plan is you would run all drafts through mh-format, and > > you could do that with the existing format language today. So how > > about default component formats which got your From line from the > > enviroment? > >oh, sure that would be fine. i didn't realize that was possible with >mh-format. forget i said anything. Yeah, there is an amazing amount of functionality in mh-format. I guess it would look something like: From: %<(getenv MHFROM)%|%(localmbox)%> (Or whatever ... I haven't decided what to call the format function that gets the local mailbox yet). >in any case, be sure and keep "cleanup" separate from "new features" >in your own mind, since some of us kibitzing from the sidelines keep >forgetting the distinction. :-) :-/ Sadly, it's all mashed up together :-/ --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>I didn't get to see what was inserted in the message I sent before, I >didn't cc it to myself, and the list replaces the Sender with one of >its own choosing (and without altering the Message-ID, which is broken >behaviour, not that that is relevant to nmh). Well, the off-list copy you sent me had: Sender: k...@munnari.oz.au >MH knows that it is going to be installed on systems that aren't >"correctly" configured (whatever your idea is on what that should be) >but needs to work anyway, that's what a lot of the masquerade stuff is >about - it allows the person who installs nmh (MH) to configure it to do >the right thing, when the default code, that extracts the info from the >system, cannot possibly work. Well, AFAICT you'll still be able to configure it to put whatever you want in there. I don't see how turning on draft_from support always changes any of this. nmh may be broken now, but my proposed changes wouldn't change the brokenness. I lack the energy to solve this problem completely; you are of course welcome to contribute code. And if you really hate this behavior ... well, there's always spost :-) --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
i wrote: > ken wrote: > > pgf wrote: > > >i didn't know about user_extension until just now. it's a pretty modern > > >feature, as these things go, though it would probably be more generally > > >useful if it allowed for substituting the entire username, rather than > > >just appending to it. in any case, i suspect it's a new enough feature > > >(the man page even references qmail :-) that people are probably still > > >using it. > > > > Sigh. So you want to keep this? Or do you want to have this instead? > > sorry. i was rambling. i'm only saying that it should be dropped, argh. that should say "shouldn't", above.-pgf > because, a) it's a pretty new feature, > so there are probably people actively using it, and b) it's quite a > useful feature -- on the fly modification (albeit limited) of the From: > address, in a way that caters to the variable-recipient feature found > in all major MTAs today. (i.e., pgf+mh@... or pgf-mh@...) =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 32.4 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
ken wrote: > pgf wrote: > >i didn't know about user_extension until just now. it's a pretty modern > >feature, as these things go, though it would probably be more generally > >useful if it allowed for substituting the entire username, rather than > >just appending to it. in any case, i suspect it's a new enough feature > >(the man page even references qmail :-) that people are probably still > >using it. > > Sigh. So you want to keep this? Or do you want to have this instead? sorry. i was rambling. i'm only saying that it should be dropped, because, a) it's a pretty new feature, so there are probably people actively using it, and b) it's quite a useful feature -- on the fly modification (albeit limited) of the From: address, in a way that caters to the variable-recipient feature found in all major MTAs today. (i.e., pgf+mh@... or pgf-mh@...) > > >okay, as long as you're in there -- i'll lobby for an environment > >variable that lets one replace the whole From: line -- it would be used > >in favor of .mh_profile if it exists. > > Well, the plan is you would run all drafts through mh-format, and you > could do that with the existing format language today. So how about > default component formats which got your From line from the enviroment? oh, sure that would be fine. i didn't realize that was possible with mh-format. forget i said anything. in any case, be sure and keep "cleanup" separate from "new features" in your own mind, since some of us kibitzing from the sidelines keep forgetting the distinction. :-) :-/ paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 32.7 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>Which brings up a question - is it sane to try to support >per-destination customization? I can probably do the things I'd want >in replcomps and friends, *if* there was a way to say "emit this header >for matches in 'to' for this pattern, but emit this other header for >non-match recipients". You can't see it, but I'm making the "warding off the evil eye" sign at you :-) --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On Tue, 07 Feb 2012 10:14:53 +0700, Robert Elz said: > Really? How do you propose making that work? Look at the From: header > of this message One wonders how many MUAs out there choke at that. Does Outlook/Exchange manage to cope with that? > Please read the mail standards before proposing changing the way MH works, > don't rely on e-mail being just what you commonly see, or what other e-mail > clients permit (many of which have similarly been created by people who > have no idea what e-mail is supposed to permit.) There's all sorts of neat stuff allowed by the RFCs. Unfortunately, my actual use of said features is in practical terms restricted to those things that don't make our Exchange admin come looking for me if I accidentally use the feature when I send my boss e-mail... Which brings up a question - is it sane to try to support per-destination customization? I can probably do the things I'd want in replcomps and friends, *if* there was a way to say "emit this header for matches in 'to' for this pattern, but emit this other header for non-match recipients". Unfortunately, that would require send/post to grow the ability to send multiple SMTP envelopes with differing headers. Ouch. pgpm4H7pCnV3s.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On Mon, 06 Feb 2012 22:41:14 EST, Ken Hornstein said: > I'm not changing the way nmh works, Robert. It already does that today, > as shipped, by default. All I'm proposing is that we remove the code that > lets you turn off that behavior ... because it's a gigantic mess and > I can't see the point of turning that code off. +1 to that... pgpybSuJPGmXJ.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Date:Mon, 06 Feb 2012 22:41:14 -0500 From:Ken Hornstein Message-ID: <201202070341.q173fepw025...@hedwig.cmf.nrl.navy.mil> | For the record ... it looks like what nmh does is that it picks the | last one and uses that as the envelope from. That's broken, none of the From: addresses necessarily meets the (semantic) requirements for the Sender (and envelope from). I didn't get to see what was inserted in the message I sent before, I didn't cc it to myself, and the list replaces the Sender with one of its own choosing (and without altering the Message-ID, which is broken behaviour, not that that is relevant to nmh). But the Sender in my message should have been k...@epsilon.noi.kre.to If it wasn't in the copy you should have received without passing through the list, then nmh is broken. I didn't put a Sender header in the draft (not even sure if nmh permits me to, there are certainly some it won't allow) that value is what should have been calculated. One of the things MH always stood for was interpreting the mail standards strictly, not just "anything that make other mailers happy" - and much of the complexity is there to try as hard as possible to make that be true. MH knows that it is going to be installed on systems that aren't "correctly" configured (whatever your idea is on what that should be) but needs to work anyway, that's what a lot of the masquerade stuff is about - it allows the person who installs nmh (MH) to configure it to do the right thing, when the default code, that extracts the info from the system, cannot possibly work. Please don't reduce nmh to being just another mailer in the "as long as it works with outlook it is OK" camp that so many others have fallen into. It must continue to be semantically, as well as syntactically, correct. Even if the code to do that is not easy to make work, or understand. kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On 2012-02-06, at 7:51 PM, Joel Uckelman wrote: > I wonder how this will play with the /usr/bin/sendmail provided by > postfix. According to its man page, -om is ignored, while -oem and -ov > aren't listed at all. -om (include sender in alias expansion) is always on in postfix. -oem (mail back errors) is the default behaviour in postfix. -ov (be verbose) only affects the -watch option to post. if postfix doesn't implement it, it's no big deal. Postfix's sendmail wrapper ignores any -o* flags it doesn't understand. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Thus spake Ken Hornstein: > >I've had this in my .mh_profile almost since I started using nmh: > > > > postproc: /usr/libexec/nmh/spost > > Wow, how did you ever know to use it? Most likely, I picked that up from someone else at Iowa State. There were a huge number of nmh users on Project Vincent when I was there. > Not exactly. > > _if_ you have the sendmail mts configured (see mts.conf) then what will > happen is sendmail gets invoked with the following flags: > > -bs -oem -om -ov I wonder how this will play with the /usr/bin/sendmail provided by postfix. According to its man page, -om is ignored, while -oem and -ov aren't listed at all. -- J. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>Really? How do you propose making that work? Look at the From: header >of this message, which should be the same as the From: header in the >draft that I am currently typing, and try to figure out how to make that >fit the rules for the envelope from. I'm not changing the way nmh works, Robert. It already does that today, as shipped, by default. All I'm proposing is that we remove the code that lets you turn off that behavior ... because it's a gigantic mess and I can't see the point of turning that code off. For the record ... it looks like what nmh does is that it picks the last one and uses that as the envelope from. Hm, didn't even know that would work; that's the second new nmh thing I learned today. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Date:Mon, 06 Feb 2012 18:59:17 -0500 From:Ken Hornstein Message-ID: <201202062359.q16nxipo024...@hedwig.cmf.nrl.navy.mil> | I think that | we should simply remove the flag and always use the From: | header in the draft as the envelope from. Really? How do you propose making that work? Look at the From: header of this message, which should be the same as the From: header in the draft that I am currently typing, and try to figure out how to make that fit the rules for the envelope from. Please read the mail standards before proposing changing the way MH works, don't rely on e-mail being just what you commonly see, or what other e-mail clients permit (many of which have similarly been created by people who have no idea what e-mail is supposed to permit.) kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>>>yes! please either keep it, or improve post by giving it a switch that >>>allows it to submit mail to an mta/msp program directly. >> >>E ... you know about the sendmail mts, right? > >i do indeed - but post always talks smtp, even with mts: sendmail. > >i need something that submits to a program on stdin without any >to-and-fro interaction - which is precisely what spost does. Really? I'm curious ... why? Let me put it another way. I lack the energy to make spost work; basically, if the changes I make in terms of From: handling break spost, then I'm not going to be fixing them. Okay, that probably won't happen; I expect that it will continue to work fine in the near future; it may not work fine after the Great Mime Rototilling, though. Enough people have said that they use it that it's not going to get removed for 1.5; I'm just trying to understand what they need from spost that post doesn't provide. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On Tue, 07 Feb 2012 12:13:36 +1000 Alexander Zangerl wrote - > > On Mon, 06 Feb 2012 18:59:17 EST, Ken Hornstein writes: > >And while we're talking about post I always forget about it, but there' > s > >also spost. It opens a pipe to sendmail -t and uses that to submit email. > >It's not documented and there's a lot of duplicated code there. I propose > >to just get rid of it (because, frankly, I don't want to have to hack on tha > t > >code twice). Objections? > > yes! please either keep it, or improve post by giving it a switch that > allows it to submit mail to an mta/msp program directly. > > submitting mail via smtp is not an option (or not an ideal one) > for some of us. +1 on this. DaveF > > regards > az > > > -- > Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.a > t/ > Things should be as simple as possible, but not simpler. -- Albert Einstein ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On Mon, 06 Feb 2012 21:17:42 EST, Ken Hornstein writes: >>yes! please either keep it, or improve post by giving it a switch that >>allows it to submit mail to an mta/msp program directly. > >E ... you know about the sendmail mts, right? i do indeed - but post always talks smtp, even with mts: sendmail. i need something that submits to a program on stdin without any to-and-fro interaction - which is precisely what spost does. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Starting your usenet experience with this group is like starting your drug experiences with 500 mikes of acid with an amphetamine chaser. -- Rebecca Ore about the monastery signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>yes! please either keep it, or improve post by giving it a switch that >allows it to submit mail to an mta/msp program directly. E ... you know about the sendmail mts, right? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On Mon, 06 Feb 2012 18:59:17 EST, Ken Hornstein writes: >And while we're talking about post I always forget about it, but there's >also spost. It opens a pipe to sendmail -t and uses that to submit email. >It's not documented and there's a lot of duplicated code there. I propose >to just get rid of it (because, frankly, I don't want to have to hack on that >code twice). Objections? yes! please either keep it, or improve post by giving it a switch that allows it to submit mail to an mta/msp program directly. submitting mail via smtp is not an option (or not an ideal one) for some of us. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Things should be as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>I've had this in my .mh_profile almost since I started using nmh: > > postproc: /usr/libexec/nmh/spost Wow, how did you ever know to use it? >I must have had some reason for it once, but I can't recall what that >would have been now. If I don't have this, I presume post will be used >instead. It's not clear to me from the post man page what post will >actually do with the mail it's given. Will post simply do the same thing >that spost does these days? Not exactly. _if_ you have the sendmail mts configured (see mts.conf) then what will happen is sendmail gets invoked with the following flags: -bs -oem -om -ov (The key one here is -bs). That invokes sendmail in the "standalone" SMTP mode and post then talks SMTP to it. spost runs sendmail -t and just outputs the draft message to it. The big difference is you don't need a From: line when doing sendmail -t; you need one when doing SMTP (either talking to a remote server or via sendmail -bs). It's not clear to me what the envelope from header is set to when you're doing sendmail -bs. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Thus spake Ken Hornstein: > >> And while we're talking about post I always forget about it, but > >> there's also spost. It opens a pipe to sendmail -t and uses that to > >> submit email. It's not documented and there's a lot of duplicated > >> code there. I propose to just get rid of it (because, frankly, I > >> don't want to have to hack on that code twice). Objections? > > > >What would replace spost? > > Um ... nothing? > > spost has nothing to do with the sendmail MTS. It's is completely seperate. > The only way you'd use it is if you have a postproc configured in your > .mh_profile, and it's missing some features that post has today. I've had this in my .mh_profile almost since I started using nmh: postproc: /usr/libexec/nmh/spost I must have had some reason for it once, but I can't recall what that would have been now. If I don't have this, I presume post will be used instead. It's not clear to me from the post man page what post will actually do with the mail it's given. Will post simply do the same thing that spost does these days? -- J. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>=> draft_from - if you don't have this then post will use what it >=> thinks is your "real" from as the Sender: header (and the envelope >=> from address as well). I guess this was done to prevent undergrads >=> from easily forging email; I would submit that the days when you >=> had to know the details of SMTP to forge email are long over since >=> nearly every email client out allows you to change the from: header >=> (although I fondly remember that as a rite of passage in college ... >=> ah, good times). I think that we should simply remove the flag and >=> always use the From: header in the draft as the envelope from. > >I disagree. I was under the impression that the "From" field in >.mh_profile would be a default, particularly if nothing else was set or >could be determined as the 'right' address. Yeah, that was the plan ... and removing this wouldn't change this. I guess I wasn't clear ... I want to remove the draft_from flag in mts.conf (and from autoconf) and make it happen always, because that would simplify the code greatly. In short, draft_from would always be turned on; there would be no option to turn it off. I gather you're okay with this? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>i didn't know about user_extension until just now. it's a pretty modern >feature, as these things go, though it would probably be more generally >useful if it allowed for substituting the entire username, rather than >just appending to it. in any case, i suspect it's a new enough feature >(the man page even references qmail :-) that people are probably still >using it. Sigh. So you want to keep this? Or do you want to have this instead? >okay, as long as you're in there -- i'll lobby for an environment >variable that lets one replace the whole From: line -- it would be used >in favor of .mh_profile if it exists. Well, the plan is you would run all drafts through mh-format, and you could do that with the existing format language today. So how about default component formats which got your From line from the enviroment? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
>> And while we're talking about post I always forget about it, but >> there's also spost. It opens a pipe to sendmail -t and uses that to >> submit email. It's not documented and there's a lot of duplicated >> code there. I propose to just get rid of it (because, frankly, I >> don't want to have to hack on that code twice). Objections? > >What would replace spost? Um ... nothing? spost has nothing to do with the sendmail MTS. It's is completely seperate. The only way you'd use it is if you have a postproc configured in your .mh_profile, and it's missing some features that post has today. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
In the message dated: Mon, 06 Feb 2012 18:59:17 EST, The pithy ruminations from Ken Hornstein on <[Nmh-workers] masquerade settings & spost> were: => Greetings all, => => I've been (slowly) working on sorting out the whole From: mess that => was discussed earlier, and of course like many things in nmh there are => a ton of assumptions that makes this a lot harder than it needs to be. => But I digress ... Many thanks for all your work! => => I came across the code in post that handles the masquerade settings and I've => realized that a) it makes post more complex, and b) I don't think we need => it, especially since we're switching to configuring our userid in .mh_profile. => => To remind everyone, there are currently three settings in mts.conf for => masquerade: => => draft_from - if you don't have this then post will use what it thinks is => your "real" from as the Sender: header (and the envelope from => address as well). I guess this was done to prevent undergrads => from easily forging email; I would submit that the days when => you had to know the details of SMTP to forge email are long => over since nearly every email client out allows you to change => the from: header (although I fondly remember that as a rite => of passage in college ... ah, good times). I think that => we should simply remove the flag and always use the From: => header in the draft as the envelope from. I disagree. I was under the impression that the "From" field in .mh_profile would be a default, particularly if nothing else was set or could be determined as the 'right' address. Like most of us, I've got multiple mail address personality disorder. I set the body From: to several different addresses daily. I really don't want the envelope and body From addresses to differ. Certainly, if nothing is set, then the value in .mh_profile should be used for both...but if the user does set the body From to something else, I'd like to see that masqueraded in the envelope too. => => mmailid- Allows you to format your GECOS field so the envelope from => will be taken from the GECOS field. I can see getting rid of this. => => username_extension - Adds $USERNAME_EXTENSION to the your userid. And this too... => => Like I said, I don't believe draft_from is relevant in the modern email => world, and if we're going to configuring your userid in .mh_profile I think => that's a better way of accomplishing the last two. I propose to junk it => all. Thanks, Mark => => And while we're talking about post I always forget about it, but there's => also spost. It opens a pipe to sendmail -t and uses that to submit email. => It's not documented and there's a lot of duplicated code there. I propose => to just get rid of it (because, frankly, I don't want to have to hack on that => code twice). Objections? => => --Ken => => ___ => Nmh-workers mailing list => Nmh-workers@nongnu.org => https://lists.nongnu.org/mailman/listinfo/nmh-workers => ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
Thus spake Ken Hornstein: > > And while we're talking about post I always forget about it, but there's > also spost. It opens a pipe to sendmail -t and uses that to submit email. > It's not documented and there's a lot of duplicated code there. I propose > to just get rid of it (because, frankly, I don't want to have to hack on that > code twice). Objections? > What would replace spost? -- J. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
ken wrote: > Greetings all, > > I've been (slowly) working on sorting out the whole From: mess that > was discussed earlier, and of course like many things in nmh there are > a ton of assumptions that makes this a lot harder than it needs to be. > But I digress ... > > I came across the code in post that handles the masquerade settings and I've > realized that a) it makes post more complex, and b) I don't think we need > it, especially since we're switching to configuring our userid in > .mh_profile. > > To remind everyone, there are currently three settings in mts.conf for > masquerade: > > draft_from - if you don't have this then post will use what it thinks is > your "real" from as the Sender: header (and the envelope from > address as well). I guess this was done to prevent undergrads > from easily forging email; I would submit that the days when > you had to know the details of SMTP to forge email are long > over since nearly every email client out allows you to change > the from: header (although I fondly remember that as a rite > of passage in college ... ah, good times). I think that > we should simply remove the flag and always use the From: > header in the draft as the envelope from. > > mmailid- Allows you to format your GECOS field so the envelope from > will be taken from the GECOS field. > > username_extension - Adds $USERNAME_EXTENSION to the your userid. > > Like I said, I don't believe draft_from is relevant in the modern email > world, and if we're going to configuring your userid in .mh_profile I think > that's a better way of accomplishing the last two. I propose to junk it > all. i agree for draft_from and mmailid. i didn't know about user_extension until just now. it's a pretty modern feature, as these things go, though it would probably be more generally useful if it allowed for substituting the entire username, rather than just appending to it. in any case, i suspect it's a new enough feature (the man page even references qmail :-) that people are probably still using it. okay, as long as you're in there -- i'll lobby for an environment variable that lets one replace the whole From: line -- it would be used in favor of .mh_profile if it exists. paul > > And while we're talking about post I always forget about it, but there's > also spost. It opens a pipe to sendmail -t and uses that to submit email. > It's not documented and there's a lot of duplicated code there. I propose > to just get rid of it (because, frankly, I don't want to have to hack on that > code twice). Objections? > > --Ken > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 37.6 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] masquerade settings & spost
Greetings all, I've been (slowly) working on sorting out the whole From: mess that was discussed earlier, and of course like many things in nmh there are a ton of assumptions that makes this a lot harder than it needs to be. But I digress ... I came across the code in post that handles the masquerade settings and I've realized that a) it makes post more complex, and b) I don't think we need it, especially since we're switching to configuring our userid in .mh_profile. To remind everyone, there are currently three settings in mts.conf for masquerade: draft_from - if you don't have this then post will use what it thinks is your "real" from as the Sender: header (and the envelope from address as well). I guess this was done to prevent undergrads from easily forging email; I would submit that the days when you had to know the details of SMTP to forge email are long over since nearly every email client out allows you to change the from: header (although I fondly remember that as a rite of passage in college ... ah, good times). I think that we should simply remove the flag and always use the From: header in the draft as the envelope from. mmailid- Allows you to format your GECOS field so the envelope from will be taken from the GECOS field. username_extension - Adds $USERNAME_EXTENSION to the your userid. Like I said, I don't believe draft_from is relevant in the modern email world, and if we're going to configuring your userid in .mh_profile I think that's a better way of accomplishing the last two. I propose to junk it all. And while we're talking about post I always forget about it, but there's also spost. It opens a pipe to sendmail -t and uses that to submit email. It's not documented and there's a lot of duplicated code there. I propose to just get rid of it (because, frankly, I don't want to have to hack on that code twice). Objections? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
