Re[2]: HTML email "bug", of sorts.

[Walter Hop <walter () binity com>]

> 1) how do you determine what's legitimate HTML email and what isn't?  Can
> pattern-matching of web bugs be as easy as "*.gif\?.*" or something
> similar?

This is ineffective; a spammer _could_ use a CGI script in the form of
http://www.spammer.com/transparent.gif?4747683621, but if these get
blocked by a popular mailer, they will just move on to other schemes,
like:

http://www.spammer.com/validate/4747683621.html
http://www.spammer.com/validate/4747683621/
http://4747683621.spammer.com/
http://4747683621.spammer.com:25/

This will make filtering of HTML content useless. Furthermore, the html
IMG tag is not the only "dangerous" tag in this aspect. There are many
more other tags to filter, which would require considerable effort on
the part of mailer developers. [The usual scenario for this is that even
years later, holes will be found.]

Some mailers like "The Bat" have their own HTML engine that refuses to
do HTTP requests at all. This seems the best solution.

Disabling HTTP requests totally will certainly break some legitimate
HTML email, but not to the point where it is totally unreadable. Most
HTML emails (stationery etc.) only refer to images enclosed with the
message, so Your Client who likes to write emails with nice green leaves
in the borders will not be disappointed by this feature.

For other HTML mailers like Outlook and Netscape, an application-level
firewall (PGP Corporate Desktop, ZoneAlarm, etc.) is the only way to go.
The best thing is not to allow the mailer any access to the network
apart from the mail protocol ports on known pop3/imap/smtp-servers used.
As shown in example URL 4 above, just blocking access to port 80 or any
non-mail port provides only a false sense of security.

--
 Walter Hop <walter () binity com> | +31 6 24290808 | Finger for public key