| Scott Schwartz <schwartz(_at_)bio(_dot_)cse(_dot_)psu(_dot_)edu> 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.
That's not an argument. An argument is a connected series of statements
intended to establish a proposition. That's just contradiction.
If you personally don't care about setting the envelope sender, then
say that.
| >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.
I've never done it that way. ``sendmail -t'' is the unix standard
mail injection mechanism. It has many advantages. It provides an
easy way to set the envelope. It means that every workstation doesn't
have to listen on port 25 and deal with network traffic from randoms.
It means that the mail injection system can authenticate the sender,
and enforce policy. nmh shouldn't be usurping that job.
| If qmail receives a message with smtp, and still sets the envelope
| sender from the "Return-Path:", then qmail is broken.
Rest easy, qmail-smtp doesn't do that. qmail-inject uses return-path
to set the envelope. /usr/lib/sendmail is a link to qmail-inject.
| We should not change nmh to make a special case that depends on
| a particular broken MTA (if qmail is that broken).
Look, right now nmh goes to extra trouble to prevent me from doing
something that has no negative consequences. Why is it tripping
me up? What is the advantage?
I think allowing return-path is a positive good. My very high
quality MTA uses it in a beautiful way. Why deny me this?
| 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.
So to get around the problem of MH having non-necessary extra
code, you want me to write more extra non-necessary code?
How about if we just delete the B&D stuff, and have better results with
less code?
| I manage to do this with the masquerading facilities already
| present.
I'm glad you're satisfied, but they're not good enough for me.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://mail.nongnu.org/mailman/listinfo/nmh-workers