TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Dick Margulis responded to my comments: <<You're right about how real spam
abuses the unsubscribe device, but that is no reason for spam filters to
have such an assumption built in.>>
Oh, I agree fully. I was just reporting _why_ someone would configure
software that way, and didn't make it clear I was talking about someone
else's logic. I could tell you long stories about incompetently installed
spam filters, but not from this address.
<<As any legitimate marketing message is required to have instructions for
unsubscribing or opting out, you cannot use the
existence of such instructions as a scoring criterion. That's just
incompetent software design.>>
More often incompetent adminstrators misconfiguring overly permissive
(customizable) software. Again, not something I'll elaborate upon from work.
<<What I'm interested in solving is the problem of their not receiving the
emails in the first place.>>
Not sure there's any good solution for that, other than requiring
adminstrators to have a cup of coffee and ask for a reality check before
configuring a spam filter. The purpose of white lists is to let the users
tell the administrator whose mail to accept no matter what the filter says.
That works just fine if the administrator is willing to listen to the users
and activate the white list feature. In my experience, most aren't willing
to make that effort until someone influential (above them in the pecking
order) complains.
<<One time we sent out an HTML email to our list that had been put together
by another organization (a non-profit conference sponsor). I neglected to
inspect the code for javascript, which it contained. That message was
blocked by a much larger number of companies whose filters--legitimately, in
my opinion--checked incoming HTML for any script content. I have no problem
with that. I also have no problem with filters that block anything
containing a virus.>>
Ditto. After all, there's no possible reason to allow a known virus through.
Wish my ISP understood that. I figure it'll take a class-action suit to make
them wake up.
<<I'm not aware of graphics being a problem. I mean, yes, I'm aware that the
existence of a linked graphic causes some people's filters to block a
message; but I'm not familiar with bugs that can be carried by graphics. Can
you elaborate on that?>>
<<And how, exactly, would you recommend constructing an HTML email that
contained, say, your company logo and a photo of the keynote speaker,
without resorting to linked graphics. Surely, you don't suggest
MIME-encoding the graphics and embedding them in every message. That would
be an even more egregious waste of bandwidth.>>
I _wouldn't_ and _don't_ recommend HTML e-mail to begin with, but if that's
what you're stuck with, my recommendation would be to use as little HTML
content as possible and still link to the newsletter. If the company logo is
required, then by definition you have to stick it in, whether by embedding
or by linking.
Contrary to what you might expect, MIME encoding is a reasonable
solution--it's what we use for our newsletter. Yes, the bandwidth
requirements are higher _when the e-mail is downloaded_, but the overall
effect on the user should be nearly identical to the alternative (linking to
the graphic): the same number of bytes have to be transferred, whether those
bytes are part of the message or must be downloaded from a Web site.
Arguably, the linking approach is a bit more efficient because it doesn't
involve the MIME overhead, but then you have all the overhead for
establishing a Web connection and requesting the graphics files.
<<The same filters that catch "unsubscribe" also block "click.">>
Perhaps then you could just delete the verb? "Margulis Mail Manager:
www.example.com" That leaves it to the user to infer what this means, but at
least it gets you past most filters.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
(try ghart -at- videotron -dot- ca if you get no response)
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."--Bjarne Stroustrup (originator of C++ programming language)
