Garth Wallace wrote:
[snip]
>>>>That' true, but it also brings up the same security/privacy
>>>>concerns as images in HTML mail. Namely, the ability to track.
>>>>
>>>>
>>>Hmm.. Could you please explain this a little more? I don't
>>>understand exactly what you mean.
>>>
>>I junkmail you with an HTML page. That page has an image loaded via a
>>CGI script, which tracks which users have opened the email
>>
>
> To highlight the problem:
>
> Say I'm some scum-sucking spammer. I've got a list of email addresses
> I've collected from bots trawling webpages and Usenet. I really don't
> know how many of them are valid, unmunged addresses, but I'm betting
> some of them are legit. I send spam to every address on the list (since it
> costs as much to send a million emails as it does to send one), with an
> attachment that references a "file" on my server that is actually a CGI
> "gotcha.cgi?victim=<emailaddr>" (where <emailaddr> is the recipient's
> email address) that records every <emailaddr> requested and returns
> some graphic. I can then take the list of addresses my CGI script has
> collected and use them as a list of "proven suckers" to send all of my
> spam to. I could even sell the list to my scum-sucking spammer pals, who
> then would send all their spam to those addresses, etc.
>
> I think message/external-body is a good idea, but only if the attachment
> is never downloaded automatically. There would always have to be a
> warning that the attachment is not part of the message (not necessarily
> even a warning dialog--just putting "[external]" next to the filename in the
> attachments list should do the trick). Warnings for external attachments
> with Content-Disposition: inline would be more difficult, but it's not
> insurmountable.
>
My basic idea is to not use message/external-body - the prime reason is
that if we send such a message there will be a lot of clients out there
which cannot handle it. Instead, I think we should send a really short
HTML attachment which reads something like "The attachment (11 Mbyte)
can be retreived as <link> within 7 days from this message" (see the
previous, long post). This gives two advantages:
- It's understood by anyone who can handle HTML attachments with
links. That should be most of us.
- It's only downloaded after user user intervention.
The risk is still there, though. On the other hand, I think this is just
the normal risk level for HTML attachments, and this is something we
have decided to accept. Or?
--michael
