| Return-Path isn't - that's only intended for mail delivery, messages should
| never contain one of those until they're being delivered (and anyone who
| believes they should should thank any mailer that corrects them).
Letting users supply return-path is both reasonable and necessary.
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. 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.
SMTP servers making final delivery MAY remove Return-path headers
before adding their own.
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; if it's the latter, it _might_ be okay
(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 one hand, your MTA is in charge of checking the input (because any
user can talk directly to it.) Mine (qmail) does, and so anything my MUA
(MH) does is at best redundant. But in this case MH is actively causing
problems, because it isn't enforcing the correct rules. qmail uses
user-supplied return-path to set the envelope sender on outgoing messages
(and removes the return-path header from the message.) That's perfectly
sensible, and very nice.
It seems like a knob that lets you adjust the SMTP envelope From
address is really what you want, rather than using Return-Path
particularly. I'm open to suggestions as to the best way to implement
such a knob. I think the functionality is valuable, certainly.
I use it all the time to convince mailing list
software that checks the envelope that I'm posting from the address they
have on file, for example.
Is that why I have to approve every mail to nmh-workers from you? :-/
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://mail.nongnu.org/mailman/listinfo/nmh-workers