[ietf-dkim] Re: SSP and Sender header field
hsantos at santronics.com
Thu Oct 27 13:45:15 PDT 2005
From: "Earl Hood":
> On October 27, 2005 at 00:47, "Hector Santos" wrote:
>> Of course, in all cases, the backend can serve ALL MUAs by writing
>> to the body of the text. But IMO, that may be borderline ethical and a
>> bad idea overall to open Pandora's box to begin changing text
[Note: I meant to type "unethical"]
> Not to mention potential legal problems. We tend to overlook copyright
> law on these matters.
I don't. But yes, it is a concern to see a growing ignorance over the years
and the trend to 'reframe' presentation in audacious ways that have nothing
to do with security or technical ideas.
So how can the backend maximize the exposure of DKIM output information to
the user? Or should it? Is the only news, good news or bad news? Why
bother the user with bad news? Do we need a new and separate generic
"Alert:" header that future MUAs can use?
I mean, there is the mindset that if the email is processed and deemed safe
enough to be store by the server for user pickup, then why should the user
worry about anything else? If my ISP with his fancy DKIM service was
confident enough to store the message and I received it, then it must be ok.
In other words, should DKIM pass the buck to user or how much of the "buck"
should be passed to the user for deciding on what's good or bad?
Consider this: In Canada, I recall earlier this year, there was bill
pending that will require all ISPs to install AVS software as part of basic
ISP operations. Otherwise it will be considered mal-practice to run a ISP
service without AVS software installed. [Source: BNA Internet Law News]
Hector Santos, Santronics Software, Inc.
More information about the ietf-dkim