<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: Notifications?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Should be easy enough to whitelist daily digest.</FONT>
</P>
<P><FONT SIZE=2>My idea was to have a link for each message in the digest. The link would include an MD5 signature of the email or subject, sender and receiver combined as basic authentication. This avoids the messy authentication for each user. Of course people would be able to see these in the digest emails but how far do you want to go. I'm not too interested in maintaining yet another username/password combo.</FONT></P>
<P><FONT SIZE=2>The web page could display a list of actions to perform on that email, including Whitelist, Forward, Learn as Ham... Users would be able to select more than one action.</FONT></P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Furnish, Trever G [<A HREF="mailto:TGFurnish@herff-jones.com">mailto:TGFurnish@herff-jones.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, August 08, 2003 2:23 PM</FONT>
<BR><FONT SIZE=2>To: MAILSCANNER@jiscmail.ac.uk</FONT>
<BR><FONT SIZE=2>Subject: Re: Notifications?</FONT>
</P>
<BR>
<P><FONT SIZE=2>Actually my first thought was a daily email message with a list of messages</FONT>
<BR><FONT SIZE=2>(sender and subject), and since the goal would be to make it quick and</FONT>
<BR><FONT SIZE=2>simple, how about a checkbox by each message row and a submit button at the</FONT>
<BR><FONT SIZE=2>bottom of the message. We'd just embed a form tag in the me... Oh, wait,</FONT>
<BR><FONT SIZE=2>form tag. Nevermind. ;^)</FONT>
</P>
<P><FONT SIZE=2>But then, along the same lines, it occurs to me that putting even just a</FONT>
<BR><FONT SIZE=2>list of message senders and subjects into a digest to be sent to the user</FONT>
<BR><FONT SIZE=2>may be likely never to get there ... because it would be likely considered</FONT>
<BR><FONT SIZE=2>spam.</FONT>
</P>
<P><FONT SIZE=2>And that leads me to, "Well, that's ok, I really didn't want another daily</FONT>
<BR><FONT SIZE=2>message anyway." And THAT, leads me in turn to the idea that perhaps</FONT>
<BR><FONT SIZE=2>instead of daily digests, we could automatically create a username and</FONT>
<BR><FONT SIZE=2>password for access to a web interface that allows releasing messages. This</FONT>
<BR><FONT SIZE=2>username would just be the email address and the password something</FONT>
<BR><FONT SIZE=2>autogenerated. It would be sent to the user the first time a spam was</FONT>
<BR><FONT SIZE=2>stored, then only sent again if the user loses the password and requests it.</FONT>
</P>
<P><FONT SIZE=2>Several advantages here, not the least of which is that instead of waiting</FONT>
<BR><FONT SIZE=2>for a daily digest listing the blocked messages, the user could hit the web</FONT>
<BR><FONT SIZE=2>page as soon as they suspect a message has been blocked. For example, when</FONT>
<BR><FONT SIZE=2>Tom emails Bob a message and Bob is waiting for it, after a few minutes he</FONT>
<BR><FONT SIZE=2>doesn't have to say "It didn't come through, I bet the spamfilter got it -</FONT>
<BR><FONT SIZE=2>I'll call the helpdesk" - instead he can say "Hold on, maybe it got stuck in</FONT>
<BR><FONT SIZE=2>that dang spamfilter again - let me check."</FONT>
</P>
<P><FONT SIZE=2>Of course, immediacy of being able to check for a "stuck" message implies</FONT>
<BR><FONT SIZE=2>real-time (not batched) logging into a database or log file - otherwise the</FONT>
<BR><FONT SIZE=2>user would have to wait for MS to flush its logs.</FONT>
</P>
<P><FONT SIZE=2>-t.</FONT>
</P>
<P><FONT SIZE=2>PS: I reserve the right to be wrong. :-)</FONT>
</P>
</BODY>
</HTML>