X-no-Archive:yes
Ah! OK, what those HTML email are doing (and any web page can do this as
well) is referring to graphics by their own complete URL, which anyone with
web access should be able to get to. And such email do assume an open
Internet connection, to resolve the graphics. This is perhaps an extreme
approach, and I have to wonder what the processing costs would be for a web
page on a web server to essentially request graphics from its own server?
The advantage to doing this with a web page is that one should then be able
to move any page to any other server, and have it resolve it's links
correctly (until someone moves the link targets!). Or, in your case, send
html email and have it display the desired image with the desired
attributes, assuming the Internet connection. etc.

So, for instance, looking a Wired News emailing, it contains
<td valign="bottom" align="right" class="wired" bgcolor="#FFFFFF"><a
href="http://www.wired.com/news/0,1287,,00.html"><img
src="http://static.wired.com/news/images/wired_000000.gif" width="153"
height="30" border="0"></a></td>

This bit of coding is part of a table definition, and it happens do display
their black and white WIRED logo, next to another graphic in the same table
that displays the word NEWS, near the top of their email. Both graphics are
also clickable links to pages on the wired server.

But if you cannot assume some flavor of Outlook or other HTML-based email,
then it would seem that you would have to rely on local resolution of a page
and all that it contains, and that's not necessarily so easy either, but
here's one approach. Instead of coding for an absolute URL, go to the other
extreme, and assume some single directory. Graphics, etc., could then all be
in that same assume directory: img src=./1.gif, or a subdir: img
src=./graphics/1.gif. Zip these into a self extracting archive that not only
decompresses the whole thing into the tmp directory, the invokes the page:
page.html, which should resolve to the preferred web browser.

But this approach would either assume the availability of an unzipper or
require you send a self-extracting archive which then assumes a platform on
which to run, doesn't it? Unless you assume Java and send jars... Does that
support self-extraction, and how would you autoexecute?

Interesting problem! In any case, using perl to send the email itself isn't
too painful, and is certainly possible. Thinking about it, it seems that
when I've signed up for wanted email, many of them have me choose text-only
or HTML.

Greg Stigers
http://www.cgiusa.com