One of the authors of this RFC, which was published in March 1999, was none other than a A. Hopmann at Microsoft Corporation:
11.1 Security considerations not related to caching It is possible for a message sender to misrepresent the source of a multipart/related body part to a message recipient by labeling it with a Content-Location URI that references another resource. Therefore, message recipients should only interpret Content-Location URIs as labeling a body part for the resolution of references from body parts in the same multipart/related message structure, and not as the source of a resource, unless this can be verified by other means. URIs, especially File URIs, if used without change in a message, may inadvertently reveal information that was not intended to be revealed outside a particular security context. Message senders should take care when constructing messages containing the new header fields, defined in this standard, that they are not revealing information outside of any security contexts to which they belong. Some resource servers hide passwords and tickets (access tokens to information which should not be reveled to others) and other sensitive information in non-visible fields or URIs within a text/html resource. If such a text/html resource is forwarded in an email message, this sensitive information may be inadvertently revealed to others. Since HTML documents can either directly contain executable content (i.e., JavaScript) or indirectly reference executable content (The "INSERT" specification, Java). It is exceedingly dangerous for a receiving User Agent to execute content received in a mail message without careful attention to restrictions on the capabilities of that executable content. HTML-formatted messages can be used to investigate user behaviour, for example to break anonymity, in ways which invade the privacy of individuals. If you send a message with a inline link to an object which is not itself included in the message, the recipients mailer or browser may request that object through HTTP. The HTTP transaction will then reveal who is reading the message. Example: A person who wants to find out who is behind an anonymous user identity, or from which workstation a user is reading his mail, can do this by sending a message with an inline link and then observe from where this link is used to request the object.