>| Hm. I did some research, and I'm going to have to side with kre on this >| one. RFC 2822 clearly states: >| >| A message-originating SMTP system SHOULD NOT send a message that >| already contains a Return-path header. > >That's actually 2821, I think.
Whoops, you're right, my apologies. >It doesn't apply because nmh is not a message originating SMTP system, >it's just a mail user agent. Hm. If you're using the SMTP mts mechanism for nmh, I'd say that it was, actually. I mean, it's speaking the SMTP protocol ... how is that not a "message originator"? It seems to fit the definition of a "originating system" under section 2.8.3 of RFC 2821. >Even if it did apply, a subsequent sentence in the RFC says: > > SMTP servers making final delivery MAY remove Return-path headers > before adding their own. > >So it's harmless if there is a return-path header present before >final delivery. That's why it's SHOULD NOT rather than MUST NOT. >So it is allowed. Allowed, yes. But certainly going against a "SHOULD NOT" is not a recommmended practice (and I've heard repeatedly in the IETF, "SHOULD means it should be a MUST in the next revision"). "Be conservative in what you send", and all that. >| I guess what nmh should be doing depends on whether or not it's using >| SMTP or "pipe to the local MTA". If it's the former, it definately >| shouldn't allow Return-Path; > >The RFC says SHOULD, not MUST. Right ... and I said "should" as well. Problem? >| (although I personally think it's a bit bogus - clearly Return-Path was >| never meant to be used this way, and supporting a wacky qmail feature >| just doesn't strike me as a good justification). > >On the contrary, the RFC says: > > The primary purpose of the Return-path is to designate the address to > which messages indicating non-delivery or other mail system failures > are to be sent. > >There you have it. The PRIMARY purpose is to do just what qmail >is using it for. Oh, come on ... that's taken out of context, definately. That whole section talks about the insertion of the Return-path header by the final delivery agent; it doesn't say that MTAs are supposed to use it to determine the SMTP envelope. Taken together, it's talking about the Return-path header as an indication of the address to use for delivery error reporting at the final delivery stage (because at the final delivery stage, the only thing you might have _is_ the message body). Clearly you're supposed to use the envelope address for error reporting, and just tack on the Return-path at the end. I can't find any text in that section that says you should use Return-path as input to the MTA; the only references I can find are copying stuff out of the envelope from address into the Return-path header. Oh, okay, I missed one spot ... if you're a "gateway" from "elsewhere->SMTP", then in _that_ case you SHOULD delete the Return-path header, and maybe use it as the envelope address. But qmail is clearly a "message originator" in this role, _not_ a gateway (as defined by RFC 2821). Actually ... if you consider qmail performing a "relay function" (that one I'm not sure about ... I suppose that depends on site configuration), one could argue that the qmail behavior is in violation of RFC 2821: SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path headers are present. But "relay" is probably not right, if we're just talking about qmail-inject. >And since there's no other way to do it, what better justification could >there be? Especially in a world where wacky mail user agents like to >go around changing things behind your back. No other way to do it? If we're talking about nmh, today, then I agree. If we're talking about "mail originating" agents, then I _don't_ agree. If you're a MUA that speaks SMTP, then obviously you should be setting the envelope address (and that's the only thing you _can_ use). If you're a MUA that opens a pipe to sendmail or an equivalant, you can use the -f option with sendmail to set the SMTP envelope address. And it looks like to me that qmail-inject supports the -f option as well. >The way qmail does it is beautifully simple. I suppose users of other >MTAs might want this ability too, so for them I suggest that nmh parse >the return path header and use it to set the envelope sender. Sigh. My problem with this is that Return-path already has a role, and IMHO it's clear that it's role is _only_ for final delivery. I'd much prefer the use of another, nmh-specific header as the knob to adjust (e.g., "Nmh-Return-Path"), so there is no confusion and it's completely clear that this is a knob to nmh and not being passed along to the MTA in the message body. Actually ... the more I look at nmh, the more I am missing something. Nmh, as currently written, if you're using the "sendmail" MTS, is just speaking SMTP to a local sendmail process by using the -bs flag to "sendmail". If you're speaking SMTP, you are absolutely supposed to be using the SMTP envelope address in the MAIL FROM commmand, and you're supposed to be ignoring the Return-path. Exactly what is qmail doing in this case? I can at least see a tiny bit of wiggle room in the spec for the qmail-inject case if you squint hard (I don't agree with your interpretation, but I can at least follow the logic), but I don't think there is any validity to this argument if you're speaking SMTP, and nmh can _only_ speak SMTP to inject a message into the mail system. I think we're going to have to agree to disagree on this one. --Ken _______________________________________________ Nmh-workers mailing list [EMAIL PROTECTED] http://mail.nongnu.org/mailman/listinfo/nmh-workers
