Scott Schwartz <[EMAIL PROTECTED]> wrote on Feb 2, 2004: >| 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. It is both unnecessary and broken. >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 nmh normally submits a message using smtp. If qmail receives a message with smtp, and still sets the envelope sender from the "Return-Path:", then qmail is broken. We should not change nmh to make a special case that depends on a particular broken MTA (if qmail is that broken). If you really want to do something special, you can define your own "postproc:" in your .mh_profile . It could even be a shell script. Use that to munge things for special purposes. It doesn't belong in the base code of nmh. > 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. Similarly, if I complain about a spammer, >I want my role account information to appear in the message, not any >personal data that MH decides the spammer ought to know. I manage to do this with the masquerading facilities already present. -NWR _______________________________________________ Nmh-workers mailing list [EMAIL PROTECTED] http://mail.nongnu.org/mailman/listinfo/nmh-workers
