| 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
Nmh-workers(_at_)nongnu(_dot_)org
http://mail.nongnu.org/mailman/listinfo/nmh-workers