On Mon, 19 Jul 2004, The Purple Streak, Hilarie Orman wrote:
However, the current discussion has, at its heart, this question:
Will OPES modify SMTP message bodies?
There is an obvious slippery slope adjacent to modification of email
content. With HTTP, the information is usually meant for many
recipients (anyone who asks). For SMTP, it is frequently
individual-to-individual, and privacy concerns are paramount. I'd
argue that a very high standard of privacy and integrity protection
should accompany any venture into this area. We need at the minimum
a document on "security and integrity guidelines for OPES SMTP
Can you help me understand why "SMTP security guidelines" are
far more important than "HTTP security guidelines"? The above text
implies, to me, that misleading millions (anyone who asks) is somehow
less important than misleading an individual. I suspect that is not
your motivation for the "SMTP security guidelines" document, but I am
not sure what is.
Certainly (IMHO), spam and phishing already educated everybody
that could be educated that they should not trust ordinary e-mails
more than an ordinary web page. Thus, we are not talking about some
elevated level of trust (compared to HTTP) that OPES ought to protect.
Perhaps we can start from a different angle: How would
"security and integrity guidelines for OPES SMTP services" document
differ from what this WG and the IAB already wrote about security
aspects of OPES?
I see some nugget of an idea about doing message body adaptation on
the mail agents themselves (the agents that store messages, like
POP3 servers), and I always felt that was the way to go for most of
the SMTP services.
IMHO, the "best" agent/location for adaptation depends on the
adaptation. For provider-authorized adaptations, SMTP agents closer to
the provider are usuallly more appropriate. That usually includes MTAs
and excludes IMAP or POP servers. For user-authorized adaptations,
SMTP agents closer to the user are usuallly more appropriate. That
often includes MTAs (when user controls them) and IMAP or POP servers.
The only compelling argument for modifying the message body "in the
network" is to remove malicious code, though even that is a slippery
There are many compelling (IMHO) arguments for adapting the message
body on the edge of the network: A group of clients behind the same
edge may want to attach a French translation to every English e-mail.
An IP-to-WAP edge may want to reformat HTML and strip images. A CDN
may want to insert local ads into mailing list postings. Doing all of
the above adaptations at the IMAP or POP server may be impractical.
(my ISP insists on removing the MIME type URL in IETF
Let's assume your ISP is using OPES for the above adaptation. If you
have authorized your ISP to adapt your e-mails by agreeing to their
policies, then there is no problem from OPES point of view. If you
have not authorized, you can take your ISP to court and/or switch ISPs
(the practically of either solution is outside of OPES scope, of