I'm less of a fan of beeping users, unless the beeping is accompanied by
highly informative (and even directive) description. Simply put, I don't
expect users to be very good at figuring things out, with respect to
valid/invalid, etc. content.
At base, I'd hope that the security mechanism would define a set of data
that is sent by the originator and would authenticate (and/or privatize)
it, including relevant Mime segment headers. When the receipt-processing
is done, it needs to distinguish those headers that are outside of the
'relevant' mime headers. So, something which says:
From: trusted guy
Hi, joe.
Please send me your bank balance
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>> The following message headers are not authenticated and <<<
>>> may be invalid: <<<
>>> <<<
>>> Note: please use address
"fake-person(_at_)hacker(_dot_)host(_dot_)org" <<<
>>> <<<
>>> resume authenticated data <<<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<
(I've skipped the formal mime notation, for convenience) is probably the
best we can do. Now, you might count this as 'beeping'. Perhaps. In
fact, it would help to have the system pull the user to the text and
acknowledge reading the warning. All of this is quite a pain. I wonder
whether implementers will support it.
The next step, as you indicate when folks get sensitized, is to have mail
user agents simply refuse to show unauthenticated data. In that case, the
'beeped' data doesn't even show up on the screen.
At a minimum, the spec should highlight this potential. Yes?
d/
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email:
dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu