Re: [Nmh-workers] File upload frustration

[Ken Hornstein]

>| 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