Re: [Nmh-workers] Changes to post
Date:Mon, 12 Mar 2012 16:48:26 -0700 From:Lyndon Nerenberg Message-ID: <045459a5-0de8-4e24-987d-9d49123b5...@orthanc.ca> | I doubt they'll be used often enough for that to be an impediment. Very possibly true, but the same applies to using a more normal looking field name - if no-one uses it much, then even if there ever was a conflict, it wouldn't really be a major problem (some people would find it difficult to use whatever new thing it conflicted with.) kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
Date:Mon, 12 Mar 2012 19:32:23 -0400 From:Ken Hornstein Message-ID: <201203122332.q2cnwnu8001...@hedwig.cmf.nrl.navy.mil> | I think you've misunderstood me; in this particular instance, OK. | Paul's proposal was to generate a Sender: header if there were multiple | From: addresses and there wasn't one already. In practice I think it more likely that there'd be a Sender field than this new one, but handling both variants is useful. | Do you mean RFC 6409? Yes. | AFAIK, we're compliant with that. I suspect that we are, anything that is doing SMTP should be. (I'm not sure that nmh can really guarantee unique message-id's but aside from that it is probably about right.) The point is that you can do less and still be submission compliant. That's why the protocol was created (otherwise we could just run normal SMTP on a different port for local use only, protocol mods wouldn't have been needed.) With an MSA, the MSA can add the Sender, rather than nmh needing to do it, as the MSA (unlike nmh) is expected to know a mailbox that works for the person actually sending the mail. Same for the envelope source address (and Date, Message-ID, etc). | In my experience with SMTP AUTH, while you can configure mailers to | require authentication and that information is logged, it doesn't | change anything else with with regards to the SMTP protocol or | message contents. Of course, with SMTP, but the submission protocol is relaxed, all kinds of things can be corrected in messages received using it. (How much any particular MSA allows depends upon it, naturally.) It was developed precisely because of the problems we're encountering, typical MUAs these days simply can't know enough. AUTH is required of the submission protocol, the MSA needs to know who the sender really is, or it would be in no better position than the MUA (just with different unknown data). kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
Hi, 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 +1 for not trampling the 822 namespace, though I see Ken's point about the short-term issues with m_getfld(). I wonder if the syntax would benefit from a colon though, so they look like headers apart from the leading dot, which we're use to in filenames as meaning `hidden'. .Mail-From: grunt+autodsnhand...@example.com If introduced, .dcc:, etc., could also be added, allowing migration to `deprecated' over the decades of future MH use. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
On 2012-03-12, at 4:32 PM, Robert Elz wrote: > Adding stuff like "nmh" in the field name would certainly reduce the > chances of a clash even further, but at the expense of making them > less manageable (for humans to deal with.) I doubt they'll be used often enough for that to be an impediment. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
Date:Mon, 12 Mar 2012 16:06:34 -0700 From:Lyndon Nerenberg Message-ID: | That sort of statement tends to lead to infamy ... Not really - there have been invented field names that have given problems, but none with rational names - sendmail's Apparently-To had all kinds of problems, but none of them related to someone else using the same name for some other purpose. Nor has MH's Fcc or Dcc. Really, just what could "Envelope-From" possibly be, other than the envelope from value? Adding stuff like "nmh" in the field name would certainly reduce the chances of a clash even further, but at the expense of making them less manageable (for humans to deal with.) kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
> | There is one wrinkle: Right now Envelope-From: can be blank; if you > | do that, then you will get a MAIL FROM:<>, which is useful if you > | don't want any bounces at all. Sounds like the logic should be if > | you have multiple From: addresses then Envelope-From: cannot be > | blank. > >There's no reason for that, there's no requirement that the smtp sender >(envelope) address be anything in particular, without regard to what's >in the From: field, nor whether or not there's a Sender field. I think you've misunderstood me; in this particular instance, Paul's proposal was to generate a Sender: header if there were multiple From: addresses and there wasn't one already. In this case it would take it from the Envelope-From: header. So in _this_ case, the Envelope-From couldn't be blank because the generated Sender: field would be blank. More of a note to myself, really. >It might be worth making sure it is only ever blank by deliberate action >however, rather than just because some other function couldn't produce >any data. I think I do that now. >But resurrecting that discussion isn't >what I intended, rather perhaps to consider what would be required using >the new mail submission protocol, which I suspect is supported by just >about all rational MTAs these days. Do you mean RFC 6409? AFAIK, we're compliant with that. If you mean something else (or I am wrong), then please let me know. >With proper use of that (sometime >in the future perhaps) many of the problems that we're having difficulty >handling should just go away - eg: as typically used these days, we >cannot expect nmh to be able to work out a valid mailbox address for >anyone - so we're more or less requiring the users to set it. On the >other hand, an MTA receiving a message through a properly authenticated >submission session should have no problem with this at all. In my experience with SMTP AUTH, while you can configure mailers to require authentication and that information is logged, it doesn't change anything else with with regards to the SMTP protocol or message contents. E.g. even though I authenticate to my mail server using SMTP AUTH, if I try an unqualified MAIL FROM command (e.g., MAIL FROM:) that command is rejected. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
On 2012-03-12, at 2:39 PM, Robert Elz wrote: > Make the name fairly precise and the chances of someone using the same > thing (including the IETF) for some different purpose are absurdly > small. That sort of statement tends to lead to infamy ... But I suppose I wouldn't grumble too loudly if we prefixed the magic header names with 'nmh-', and ensured they never leaked into the wild when the message is sent. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
Date:Mon, 12 Mar 2012 13:57:43 -0400 From:Ken Hornstein Message-ID: <201203121757.q2chviac031...@hedwig.cmf.nrl.navy.mil> | There is one wrinkle: Right now Envelope-From: can be blank; if you | do that, then you will get a MAIL FROM:<>, which is useful if you | don't want any bounces at all. Sounds like the logic should be if | you have multiple From: addresses then Envelope-From: cannot be | blank. There's no reason for that, there's no requirement that the smtp sender (envelope) address be anything in particular, without regard to what's in the From: field, nor whether or not there's a Sender field. It might be worth making sure it is only ever blank by deliberate action however, rather than just because some other function couldn't produce any data. | Actually, now that I think about it I might have written the | code that Sender can be blank, so I should fix that :-) Yes... I also see no problem with using regular field names (that could be legal) for internal purposes, and doing so certainly makes things more regular for everyone. The only thing to watch for is to avoid using field names that are too generic (Envelope-From is not going to be a problem) and that reasonably could be used for almost any purpose. Make the name fairly precise and the chances of someone using the same thing (including the IETF) for some different purpose are absurdly small. (And of course forget the X nonsense.) One final comment - much of what is being discussed (about what is required, rather than mechanism I mean) is based upon the assumption that nmh is using SMTP for message submission - we wouldn't need to be worried about envelopes, or Sender headers, if we were using sendmail type delivery (for example). But resurrecting that discussion isn't what I intended, rather perhaps to consider what would be required using the new mail submission protocol, which I suspect is supported by just about all rational MTAs these days. With proper use of that (sometime in the future perhaps) many of the problems that we're having difficulty handling should just go away - eg: as typically used these days, we cannot expect nmh to be able to work out a valid mailbox address for anyone - so we're more or less requiring the users to set it. On the other hand, an MTA receiving a message through a properly authenticated submission session should have no problem with this at all. kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
ken wrote: > > > But there is another issue that we need to address. Envelope-From: > > > is a valid message header. It's remotely conceivable that someone > > > might have a need to use it for another purpose. And there are other > > > SMTP parameters that it might be useful to set, e.g.: deliver-by. > > > I don't like the idea of co-opting yet more headers out of the 822 > > > namespace for this. > > > >is there any technical reason that the proposed Envelope-From: header > >functionality simply be named "Return-path:"? since i assume MH > >will remove this header (whatever we call it) from the draft before > >submitting to SMTP, i wouldn't think there's a conflict. > > Yes, actually, there is. okay, i can believe that. > > Think about the case when you're dist'ing a message with a Return-Path > header. There's no way to distinguish between the existing Return-Path > header and the one you would possibly add (there is already a Resent-Sender > header that post knows how to deal with). I'm assuming we don't want > a Resent-Return-Path header. experimental evidence tells me that i can't send a message with a Return-Path at all, when dist'ing messages containing one or more of them -- all but the new one have been discarded by the time the message reaches the recipient. but stracing post convinces me that it's likely postfix that's discarding them all (or perhaps gmail, which was the recipient in this case.) paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 67.1 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
> > But there is another issue that we need to address. Envelope-From: > > is a valid message header. It's remotely conceivable that someone > > might have a need to use it for another purpose. And there are other > > SMTP parameters that it might be useful to set, e.g.: deliver-by. > > I don't like the idea of co-opting yet more headers out of the 822 > > namespace for this. > >is there any technical reason that the proposed Envelope-From: header >functionality simply be named "Return-path:"? since i assume MH >will remove this header (whatever we call it) from the draft before >submitting to SMTP, i wouldn't think there's a conflict. Yes, actually, there is. Think about the case when you're dist'ing a message with a Return-Path header. There's no way to distinguish between the existing Return-Path header and the one you would possibly add (there is already a Resent-Sender header that post knows how to deal with). I'm assuming we don't want a Resent-Return-Path header. >(other SMTP directives could still be done with syntax something like >that proposed by lyndon.) To reply to Lyndon's message ... >But there is another issue that we need to address. Envelope-From: >is a valid message header. It's remotely conceivable that someone >might have a need to use it for another purpose. And there are >other SMTP parameters that it might be useful to set, e.g.: deliver-by. >I don't like the idea of co-opting yet more headers out of the 822 >namespace for this. I understand where you're coming from, but let me offer two counter points. First off, we already do this with a few other headers today. The big examples are Fcc: and Dcc:. I don't feel using Envelope-From is necessarily worse than these headers, since there is already precedence using these with post. In fairness, just because bad decisions were made in the past doesn't mean we should continue to make bad decisions now. But ... >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: My second counter-point boils down to the albatross around our collective necks: m_getfld(). post uses it to process the draft message, and it expects RFC-822 headers. I don't know what m_getfld() will do if it gets the syntax Lyndon proposed, but I for one am NOT interested in changing m_getfld() to deal wth it. In addition, the code in post is all centered around dealing with RFC-822 headers and processing them. Adding a new syntax would involve a lot of extra code that I'm personally not interested in writing now. Maybe in the future, once we've replaced m_getfld(), yeah, we could look at it. And if someone else wants to do it, even for 1.5, then I'll gladly step aside and let them tackle it. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
>What about repl and forw? Will the default `comp' files all insert an >appropriate From: that respects the mts.conf/localname setting? That's >all I want and need. Yes, _all_ default components files now do that, for all programs that use a components files. Feel free to download the sources from git and try it out yourself. As part of this change, all components files are now process by mh-format; the utilities now get some extra flags like -to, -cc, etc that make use of this feature. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
Ken Hornstein wrote: >> >Right now From: has to be set in components, replcomps, replgroupcomps, >> >etc. I currently rely on From: being set from the GECOS and localname:' >> >option from mts.conf so I don't have to set From: in all those "comp" >> >files. >> > >> >If you make the above change, will there be an .mh_profile way to set >> >the From: in a *single* place? >> >> Technically, it should be "made", as these changes have already been >> pushed to master. I covered this previously, but perhaps it wasn't >> clear. Sorry, I only recently joined the mailing list. >> The default components files now add an appropriate From: header >> to all drafts (for dist it's Resent-From). If you have your own >> components files then you'll need to change them. There is a new >> mh-format function (%(localmbox)) that you can use to specify the >> local mailbox address. By default this is retrieved from the system >> via the "normal" way (GECOS, username, hostname or localname:), but >> you can override this in your .mh_profile. What about repl and forw? Will the default `comp' files all insert an appropriate From: that respects the mts.conf/localname setting? That's all I want and need. Kevin ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
lyndon wrote: > But there is another issue that we need to address. Envelope-From: > is a valid message header. It's remotely conceivable that someone > might have a need to use it for another purpose. And there are > other SMTP parameters that it might be useful to set, e.g.: > deliver-by. I don't like the idea of co-opting yet more headers > out of the 822 namespace for this. is there any technical reason that the proposed Envelope-From: header functionality simply be named "Return-path:"? since i assume MH will remove this header (whatever we call it) from the draft before submitting to SMTP, i wouldn't think there's a conflict. (other SMTP directives could still be done with syntax something like that proposed by lyndon.) paul > > 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 > > Post would strip out all the .foo meta-headers. Since these headers will be > specific to the backend transport I would suggest ignoring ones unknown to > the > backend, and giving the backend the ability to print warnings, or abort the > send, if there are problems processing a recognized directive. > > --lyndon > > > ___ > 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 67.6 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
ken wrote: > >[ i tried to send this before, but something went wrong, and ken's > >moving so fast these days, i feel compelled to resend asap. :-) ] > > You say that like it's a bad thing! :-) are you kidding!? it's great! now, when someone calls me a luddite for using such a clunky archaic mailer, i can reply with a snappy, "hey! it is _not_ dilapidated. in fact, it got a new feature, just the other day, thanks to my new hero Ken!". ;-) paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 66.4 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
>[ i tried to send this before, but something went wrong, and ken's >moving so fast these days, i feel compelled to resend asap. :-) ] You say that like it's a bad thing! :-) >- if there are multiple addresses in From:, then require at least >one of Envelope-From: or Sender:. create a Sender: from >Envelope-From: if necessary, to satisfy the RFC. >- Choose the SMTP envelope header from >1) Envelope-From: >2) Sender: (no "iff" -- i don't think there's a need for that) >3) From: Hm. You know, I like this (and it seems that there is widespread agreement that Sender: should always override From:). There is one wrinkle: Right now Envelope-From: can be blank; if you do that, then you will get a MAIL FROM:<>, which is useful if you don't want any bounces at all. Sounds like the logic should be if you have multiple From: addresses then Envelope-From: cannot be blank. Actually, now that I think about it I might have written the code that Sender can be blank, so I should fix that :-) --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
>Right now From: has to be set in components, replcomps, replgroupcomps, >etc. I currently rely on From: being set from the GECOS and localname:' >option from mts.conf so I don't have to set From: in all those "comp" >files. > >If you make the above change, will there be an .mh_profile way to set >the From: in a *single* place? Technically, it should be "made", as these changes have already been pushed to master. I covered this previously, but perhaps it wasn't clear. The default components files now add an appropriate From: header to all drafts (for dist it's Resent-From). If you have your own components files then you'll need to change them. There is a new mh-format function (%(localmbox)) that you can use to specify the local mailbox address. By default this is retrieved from the system via the "normal" way (GECOS, username, hostname or localname:), but you can override this in your .mh_profile. These changes were made a little while ago; the new stuff is the rejection of drafts without From: headers in them. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
On 2012-03-12, at 9:26 AM, Earl Hood wrote: > 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. The IETF consensus is that X-headers are going to die. But regardless, we're still co-opting 822 header space for non-822 purposes. It's better to just fix the problem correctly. --lyndon ___ 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] Changes to post
ken wrote: > So here's what I came up with: > > - Reject drafts that don't have a From: header (this was non-controversial > as I recall). > - Allow a Sender: header in the drafts (previously post would reject > drafts that had one; I assume that's because post had it's own idea > what your "real" address was). > - _Require_ a Sender: header in your draft if you have multiple addresses > in your From: header. This is actually required by the RFCs, although > in my limited tests it seems that this restriction is not enforced. > But we should still make sure we're not sending out email that is > broken (okay, we do that today for other things, but hey, that's no > excuse for making it worse). > - Create a new draft header called Envelope-From: (not copied into the > outgoing message). > - Choose your SMTP envelope header out of the following list (starting > with highest priority). > > 1) Envelope-From: > 2) Sender:, iff you have multiple addresses in From: > 3) From: can i propose a slight loosening of all this? i like the idea of the Envelope-From: header for specifying the SMTP header, and in my mind the only reason for the Sender: header is because the RFC requires it -- it adds no value for most people otherwise. so: - Require a From: header in the draft. - Create a new, optional, Envelope-From:, and allow it in the draft. - Allow a Sender: header in the draft (nothing changed so far) - if there are multiple addresses in From:, then require at least one of Envelope-From: or Sender:. create a Sender: from Envelope-From: if necessary, to satisfy the RFC. - Choose the SMTP envelope header from 1) Envelope-From: 2) Sender: (no "iff" -- i don't think there's a need for that) 3) From: this would let most people forget all about Sender: if they choose to (while still satisfying the RFC), and it creates a new means of easily forcing the return address for bounces on mail with any number of addressess in the From: line. paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 43.0 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
On 2012-03-12, at 9:05 AM, Lyndon Nerenberg wrote:
> Since these headers will be specific to the backend transport I would suggest
> ignoring ones unknown to the backend, and giving the backend the ability to
> print warnings, or abort the send, if there are problems processing a
> recognized directive.
The sender should also be able to specify the message not be sent if a
meta-directive cannot be honoured. E.g. trying to specify deliver-by when
using the sendmail transport. Changing to:
directive = LETTER *(LETTER / DIGIT / "-") *("!")
would make
.deliver-by 86400 N
a request, and
.deliver-by! 86400 N
a demand.
--lyndon
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
>> - Reject drafts that don't have a From: header (this was non-controversial >> as I recall). Right now From: has to be set in components, replcomps, replgroupcomps, etc. I currently rely on From: being set from the GECOS and localname:' option from mts.conf so I don't have to set From: in all those "comp" files. If you make the above change, will there be an .mh_profile way to set the From: in a *single* place? Kevin ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
On 2012-03-11, at 8:39 PM, Ken Hornstein wrote: > My thinking was that since bounces go to the SMTP envelope-from, > bounces should go back to the person who wrote the message. In the > example above, I'd want to know about a bounced email, rather than > my secretary (I guess I could see other people NOT wanting to deal > with that, though). But since it's not obvious what to use when > there are multiple addresses in From:, Sender: should be the one > that should be used. But since I could imagine wanting to override > that, that's why I created Envelope-From:. The intent for Sender: is that it represent the entity responsible for the transmission and delivery of the message, and that explicitly includes handling DSNs, therefore the Sender: address should always be used as the MAIL FROM address, if it's present. But even in the presence of Sender:, the Envelope-From: should override Sender: to allow for the scenario where b...@example.com sends a message on behalf of a...@example.com, but wants DSNs directed at b+...@example.com. E.g.: From: b...@example.com Sender: gr...@example.com Envelope-From: grunt+autodsnhand...@example.com This makes it clear that grunt initiated the message on behalf of boss while allowing grunt to point DSNs at a filter that automatically processes those DSNs. Thus the MAIL FROM construction logic would be: * use envelope-from, if present * use sender:, if present * if multiple from: and no sender:, abort * use from: address But there is another issue that we need to address. Envelope-From: is a valid message header. It's remotely conceivable that someone might have a need to use it for another purpose. And there are other SMTP parameters that it might be useful to set, e.g.: deliver-by. I don't like the idea of co-opting yet more headers out of the 822 namespace for this. 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 Post would strip out all the .foo meta-headers. Since these headers will be specific to the backend transport I would suggest ignoring ones unknown to the backend, and giving the backend the ability to print warnings, or abort the send, if there are problems processing a recognized directive. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
On 3/12/2012 9:53 AM, Tethys wrote: > As such, I'd say if Sender is present, always prefer it over From, > regardless of how many From addresses there are. This will hold > true even if you don't have a secretary. If you've specified a > Sender, I can't imagine why you'd want bounces to go elsewhere. i agree. i did not understand the "iff" in ken's proposal. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
[ i tried to send this before, but something went wrong, and ken's moving so fast these days, i feel compelled to resend asap. :-) ] ken wrote: > So here's what I came up with: > > - Reject drafts that don't have a From: header (this was non-controversial > as I recall). > - Allow a Sender: header in the drafts (previously post would reject > drafts that had one; I assume that's because post had it's own idea > what your "real" address was). > - _Require_ a Sender: header in your draft if you have multiple addresses > in your From: header. This is actually required by the RFCs, although > in my limited tests it seems that this restriction is not enforced. > But we should still make sure we're not sending out email that is > broken (okay, we do that today for other things, but hey, that's no > excuse for making it worse). > - Create a new draft header called Envelope-From: (not copied into the > outgoing message). > - Choose your SMTP envelope header out of the following list (starting > with highest priority). > > 1) Envelope-From: > 2) Sender:, iff you have multiple addresses in From: > 3) From: can i propose a slight loosening of all this? i like the idea of the Envelope-From: header for specifying the SMTP header, and in my mind the only reason for the Sender: header is because the RFC requires it -- it adds no value for most people otherwise. so: - Require a From: header in the draft. - Create a new, optional, Envelope-From:, and allow it in the draft. - Allow a Sender: header in the draft (nothing changed so far) - if there are multiple addresses in From:, then require at least one of Envelope-From: or Sender:. create a Sender: from Envelope-From: if necessary, to satisfy the RFC. - Choose the SMTP envelope header from 1) Envelope-From: 2) Sender: (no "iff" -- i don't think there's a need for that) 3) From: this would let most people forget all about Sender: if they choose to (while still satisfying the RFC), and it creates a new means of easily forcing the return address for bounces on mail with any number of addressess in the From: line. =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 54.9 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
I agree with Tet, and considered saying the same thing (though less eloquently) last night... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
>If you're the sort of person that has a secretary send email for you >(probably less common now than when the RFCs were drafted, but still...) >then you'd want the bounce to go to the secretary and have them deal >with it, since you're clearly too busy for such minutiae. > >As such, I'd say if Sender is present, always prefer it over From, >regardless of how many From addresses there are. This will hold true >even if you don't have a secretary. If you've specified a Sender, I >can't imagine why you'd want bounces to go elsewhere. ... alright, I think I can be persuaded by this argument, and since it's overridable with Envelope-From, it's not a huge impact if we get it wrong. Anyone else want to weigh in before I make this change? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
Ken Hornstein writes: >My thinking was that since bounces go to the SMTP envelope-from, >bounces should go back to the person who wrote the message. In the >example above, I'd want to know about a bounced email, rather than >my secretary If you're the sort of person that has a secretary send email for you (probably less common now than when the RFCs were drafted, but still...) then you'd want the bounce to go to the secretary and have them deal with it, since you're clearly too busy for such minutiae. As such, I'd say if Sender is present, always prefer it over From, regardless of how many From addresses there are. This will hold true even if you don't have a secretary. If you've specified a Sender, I can't imagine why you'd want bounces to go elsewhere. Tet ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Changes to post
I just committed some changes to "post", and I wanted to give people a heads up and solicit some feedback. The changes to "post" include the previously-discussed requirement that a From: header is now required in message drafts. But as always, there are wrinkles. The discussion I had with Robert Elz last month brought up some complications in my original plan. Specifically, Robert pointed out: - You're allowed to have multiple addresses in From: - If you do, using Sender: is required. - Neither From: nor Sender: necessarily correspond to what the SMTP envelope-from header should be. So here's what I came up with: - Reject drafts that don't have a From: header (this was non-controversial as I recall). - Allow a Sender: header in the drafts (previously post would reject drafts that had one; I assume that's because post had it's own idea what your "real" address was). - _Require_ a Sender: header in your draft if you have multiple addresses in your From: header. This is actually required by the RFCs, although in my limited tests it seems that this restriction is not enforced. But we should still make sure we're not sending out email that is broken (okay, we do that today for other things, but hey, that's no excuse for making it worse). - Create a new draft header called Envelope-From: (not copied into the outgoing message). - Choose your SMTP envelope header out of the following list (starting with highest priority). 1) Envelope-From: 2) Sender:, iff you have multiple addresses in From: 3) From: The thing I'm not so sure about is the handling of the SMTP envelope address when a Sender: header is present. Should it always override From:? The RFCs are sort of vague on how it is supposed to work. RFC 5322 says this: 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. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. I mean, I understand the words, I'm just trying to map it to my real-world usage. Example: I have two main email addresses I use: "kenh@work", and "kenh@personal". When I write a message on my home computer (which is in NEITHER the "work" domain, nor the "personal" domain), and I use a From: header that says "kenh@personal", what is the "mailbox of the agent responsible for the actual transmission of the message"? Does it depend on which SMTP server I use? It seems unknowable by nmh. My thinking was that since bounces go to the SMTP envelope-from, bounces should go back to the person who wrote the message. In the example above, I'd want to know about a bounced email, rather than my secretary (I guess I could see other people NOT wanting to deal with that, though). But since it's not obvious what to use when there are multiple addresses in From:, Sender: should be the one that should be used. But since I could imagine wanting to override that, that's why I created Envelope-From:. Anyway, feedback is welcome. I believe this was the last thing that I wanted to do for 1.5 ... so if we can come to a consensus on this behavior, we could cut a release pretty soon. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
