On 29 Jun 2016, at 11:45, Chip wrote:
I will read up on it. Thank you for the link.
Not everyone, I think, who visits this list is an engineer.
True, unless you accept Michael Wise's generous functional definition.
I'm on the fence there, as I've held job titles calling me an engineer
but my only formal engineering training was secondary to theatrical set
design and construction, i.e. to make sure actors didn't die in
collapses of not quite enough steel and/or wood. All of my education in
"software engineering" and "systems engineering" (skills I supposedly
have if you believe job titles) is from a handful of low-numbered
college classes 25+ years ago and on-the-job/self training
But Michael is entirely correct in that nearly everyone subscribed to
this list is a de facto mail system "engineer" in that we work with the
complexities of configuring and operating mail systems. So even though I
don't build bridges, haven't built a stage set in decades, and don't
write much ode these days, I DO "drive the trains" of multiple email
systems, some of which use Postfix. So I'm an engineer, I guess.
And so are you, since you seem to have run both Postfix and Exim systems
at least at the "train driver" level (and frankly, railroad engineers
ARE engineers to at least the same degree as sysadmins, but most of us
just don't have any idea how complex trains can be...)
So it would have been easier to understand if the response had been
along the lines of:
"envelope-from" instead of just FROM since there are a number of Froms
in the source code.
Someone wrote: "Return-path is a header added by the receiving MTA
(usually on final
delivery) that contains the envelope sender (MAIL FROM) used by the
sending system.
Which is accurate, if a bit ecumenical in its nomenclature...
It would definitely be helpful if everyone trying to manage mail systems
read RFC5598 (https://tools.ietf.org/html/rfc5598) carefully enough and
often enough to adopt its formal terminology. Dave Crocker's purpose in
writing that RFC was to establish precise standard jargon and a baseline
understanding of how email actually works (and is intended to work) for
people who should have such an understanding. If you're running a mail
server, whether you accept the label "engineer" or not, you should
definitely read it.
