Eric Fair writes:
I think that putting any kind of header stripping (especially
on SMTP output) into your MTA is exceedingly poor judgement on your part;
it's that kind of nonsense that gave us LISTSERV and the violence that
it does to Internet messages, by default (!!). The worst part is that
unlike you, the author of LISTSERV doesn't regret his poor judgement at
all - nay, he revels in it, despite the problems that it causes all
over the world.
First of all, header stripping is never enabled by default in the software
I write. Never. System managers must enable it themselves. Users can also
enable it themselves if they like (local delivery is completely programmable
using our software).
Second, we provide source code for our product (yes, it is commercial software,
but we still provide source code) and people have hacked this change in
themselves. In fact, various sites not only hacked it in, they did so and
distributed the diffs so everyone could do it if they wanted to. Worse, they
did not do it properly. One of the reasons for our doing it is that if you are
going to do it, you might as well do it correctly.
Third, several sites have indicated that their use of our product is contingent
on its ability to deal with these sorts of things. They don't use "your"
product (speaking only generically here) because we're not purists about stuff
like this. I sell a commercial product; I don't have the luxury of making
decisions based on Internet etiquette all the time.
In my view, you must NEVER acceed to the demand to do header
stripping in the MTA - that will keep up the pressure on the UA vendors
to fix their broken code. If the MTA vendors perform header stripping
then the UA vendors are wrongly let off the hook. If this sounds like
an uncompromising view, that's because I have been badly, badly burned
by exactly this sort of thing, and I find it reprehensible that UA
vendors don't do their jobs, AND that MTA vendors would even consider
trying to make up for those bums.
The problem is that people are gonna do it whether you or I like it or not. The
only question is, can it be done in a reasonably sanitary way so that people
will not have major trouble with it? For this reason I provide a mix of
options so that people can do the hacking they insist on -- they do not
have to take an all-or-nothing approach.
Our documentation warns, repeatedly, about the dangers of doing this. We say it
must NEVER be done on messages that are not undergoing final delivery. In fact,
we go further -- the facilities that really damage headers will not work on
channels that aren't doing final delivery.
For this reason, problems caused by header stripping should be limited to the
local sites running with this sort of local delivery. We even check to make
sure the message is not being forwarded on out again, and recover the message
headers when this is happening. When people run into problems caused by stupid
choices they have made, I say "I told you so".
It is worth noting that the usual reason this situation arises is that upper
management instructs the system manager to get rid of those messy headers or
start looking for a new job. Changing UAs is not an option. The system manager
then enables header stripping. If he or she is smart, they then disable it on
their own account. Upper management then gets burned, eventually, and the
system manager can now make a case for why the headers should not have been
stripped. The system manager is on record for disapproving of the approach, and
can point to his or her own account that did not have whatever problem was
encountered as a case in point. There is then a case for getting the headers
back and management may in fact now want to splurge on getting a new UA that
can deal with them. And yes, I have seen this exact scenario played out more
than once.
There is one case that is somewhat messier, and I freely admit its existence.
This is the use of SMTP to deliver to stupid mailers out on local systems
attached via a LAN. I am referring specifically to various products (use of
this term is charitable) that run on Macintoshes here; there are probably
culprits in the PC arena as well but I'm not familiar with those. These things
accept SMTP mail and deliver it on a local Mac or Macs, and provide fewer
viewing options that I have using a dumb terminal connected to a mainframe
running 5 year old software.
Worse, the users of these things seem to be of the sort that their poor little
heads simply burst if there's a header on the message. Any header at all. They
are the worst sort of look and feel bigots, yet they refuse to blame these
problems on their local mail software because it runs on their cherished system
that they bought and configured themselves so they could laugh at the local MIS
people, who they hate and would like to get rid of.
Even worse, the most vocal users of this stuff seem to occupy corner offices --
you know, the ones with the windows and the better carpet. They tend to send
memos that talk about downsizing and things like that. When they say they don't
want headers, they mean that they will roll heads until they get this option.
If you think I'm exaggerating, you're wrong. I know of one case personally
where a senior person in the physical plant part of a large corporation is
tasked to do one thing, and one thing only -- get the president's e-mail
delivered. That's all they do. The president insists on using a particularly
nasty example of a poor computer and mail system combo and this presents huge
problems for everyone.
And this presents a problem for me. I don't like breaking the rules of SMTP,
simply because I cannot guarantee that such things will only be used locally.
It is always possible that such material will escape onto the Internet from a
badly configured mailer. It hasn't happened thus far, largely because we have
been extremely careful to document how to set this up properly if you have to
(and with lots of stern warnings about what can go wrong). But the pressure to
implement this hack was immense and we simply could not refuse to do it. It
still worries me, however.
I think that the best thing that you could do in that situation
is become a UA vendor - with a fixed UA for those environments whose
UA's are broken. As the saying goes, this is an opportunity, not a
problem.
Guess what I'm writing at this very moment? Not only do I agree, I used exact
same saying to describe my approach in private e-mail only yesterday. Our new
UA will probably be bundled with our MTA stuff so that people won't have any
financial excuse for not using it. We demonstrated a prototype of it at
InterOp, as a matter of fact.
I am not a magician, however. I could not justify the construction of a
replacement UA that is Internet-etiquette compliant previously. The old UA
worked, and works, well enough. Despite all the yammering and puling I hear
from Internet purists on this, it always boiled down to an area that is only a
local concern (local delivery) and the reality that nobody really wanted a new
UA just because it would a bunch of purists happy.
RFC-XXXX changes this. For the first time there is a substantial incentive to
change UAs, if only so that things will interoperate with all those cute little
LAN-based mail systems. (Upgrades to the gateway code we provide for these
things are underway as well.)
Perhaps RFC-XXXX is more important because of the changes it will induce
into the infrastructure, rather than for any particular facility it provides.
Ned