[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] masquerade settings & spost

From: Ken Hornstein
Subject: [Nmh-workers] masquerade settings & spost
Date: Mon, 06 Feb 2012 18:59:17 -0500

Greetings all,

I've been (slowly) working on sorting out the whole From: mess that
was discussed earlier, and of course like many things in nmh there are
a ton of assumptions that makes this a lot harder than it needs to be.
But I digress ...

I came across the code in post that handles the masquerade settings and I've
realized that a) it makes post more complex, and b) I don't think we need
it, especially since we're switching to configuring our userid in .mh_profile.

To remind everyone, there are currently three settings in mts.conf for

draft_from - if you don't have this then post will use what it thinks is
             your "real" from as the Sender: header (and the envelope from
             address as well).  I guess this was done to prevent undergrads
             from easily forging email; I would submit that the days when
             you had to know the details of SMTP to forge email are long
             over since nearly every email client out allows you to change
             the from: header (although I fondly remember that as a rite
             of passage in college ... ah, good times).  I think that
             we should simply remove the flag and always use the From:
             header in the draft as the envelope from.

mmailid    - Allows you to format your GECOS field so the envelope from
             will be taken from the GECOS field.

username_extension - Adds $USERNAME_EXTENSION to the your userid.

Like I said, I don't believe draft_from is relevant in the modern email
world, and if we're going to configuring your userid in .mh_profile I think
that's a better way of accomplishing the last two.  I propose to junk it

And while we're talking about post .... I always forget about it, but there's
also spost.  It opens a pipe to sendmail -t and uses that to submit email.
It's not documented and there's a lot of duplicated code there.  I propose
to just get rid of it (because, frankly, I don't want to have to hack on that
code twice).  Objections?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]