feature request - FW: Just the notification for spam?

Furnish, Trever G TGFurnish at HERFF-JONES.COM
Wed Jan 21 22:15:10 GMT 2004

> -----Original Message-----
> From: Dustin Baer [mailto:dustin.baer at IHS.COM]
> Sent: Wednesday, January 21, 2004 3:08 PM
> Subject: Re: feature request - FW: Just the notification for spam?
> Doesn't this defeat the purpose of trying to stop people from
> having to
> be annoyed by spam?  With your request, a person will get a message
> (that they can filter) that tells them of quarantined spam,
> which seems
> just as annoying as getting the spam in the first place.
> Basically, you
> want to substitute spam for
> might-be-spam-but-you-have-to-open-this-email-to-find-out.

Uh, no - spam already gets filtered by users into folders.  But I still
deliver the entire message, at considerable bandwidth cost - I don't want to
keep delivering the message, but I presently don't have a suitable method of
allowing users to release their own messages, nor of having them train the
system.  Mailwatch plus spam-training mailboxes is a useful set-up (and
that's done), but as good for my situation as what I'm requesting.  And
spam-training mailboxes still require the message to be sent over the wire
again, further wasting bandwidth.

> > Recipients can filter these into a folder and ignore them
> 99% of the time
> If you modify the subjet to add {Spam?}, they can filter it anyway.

Already done, but again that does not address the waste of bandwidth, nor
the need to train SA.

> Letting them filter on something in the subject, would save them from
> having to open the email, read who it is from (which should also be
> displayed in their "spam" email folder), and then click a link.

Having to check your spam folder for a message you've been waiting on is a
tremendous improvement over having to contact a helpdesk to ask them whether
the message was blocked and is a smaller, but still significant improvement
over having to log into a web page, search for a blocked message, open the
blocked message detail report, then check some boxes to release the message.

>From the helpdesk standpoint, bayesian training will be much more effective
if it does NOT involve a user forwarding a message and will be much more
practical if they don't have to do the release/train/whitelist on behalf of
the user.

And yes, from a VP standpoint, anything that involves asking a large
userbase spread over an entire continent to remember one more
username/password combo *does* justify at least some pushback towards the
techie asking you to ok it.

> Must be a VP requesting your "feature."

In this case, IMO, that's not important because it's still a useful feature.

More information about the MailScanner mailing list