>| 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.
I believe Neil really meant to say that nmh can _only_ submit a message using SMTP. Even when it's piping to sendmail, it's not using -t, it's using -bs and speaking SMTP. The workstation doesn't have to listen on port 25 in that case, obviously. This is assuming that you haven't changed nmh to use -t (if you did, hey, that's fine ... I just want to be sure we're talking about the same thing). Whether or not you use nmh to talk to a local *mail process to inject mail or have it speak SMTP to your mailhub, well, I personally view that as a philosophical choice. However, we have nmh set up at our site to speak SMTP to the mail hub, and I will give one reason why: it lets us use SMTP AUTH to authenticate ourselves to the mail server with Kerberos authentication, and thus allow mail relaying (this is especiallly important if you're offsite). This is unfortuately very hard to do if from the context of a sendmail queue or a qmail queue, since those are generally not run in the context of the user. This is of course not valuable to everyone; I only present it as an explanation as to why someone would want to do this. >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? Nmh header processing has always been a bit ... funky. It does more than most Unix MUAs. When I dug into this, I found out this was because it speaks SMTP, so by it's very nature it's got to be more careful of headers. I suspect that's why it's going to extra trouble to strip out stuff it thinks is unnecessary, like Return-path. >I think allowing return-path is a positive good. My very high >quality MTA uses it in a beautiful way. Why deny me this? Please understand; I have no objection to the functionality. I'm just not happy with the overloading of an existing header. I'm perfectly happy with a new header (and let's be realistic; given nmh code today, you're _going_ to have to parse the header and put that in the SMTP envelope, because nmh always uses SMTP for injection). Given that it's not as simple as turning off HBAD, I'd just rather use another header so that it's perfectly clear this is an nmh knob, not a SMTP knob. --Ken _______________________________________________ Nmh-workers mailing list [EMAIL PROTECTED] http://mail.nongnu.org/mailman/listinfo/nmh-workers
