RBL check combines SMTP sender and Mail_From domains

Vernon Schryver vjs@calcite.rhyolite.com
Fri Sep 19 14:26:29 UTC 2008


> From: Gary Mills <mills@cc.umanitoba.ca>

> > I think the best tactic is to give each user a private dccm/dccifd
> > whiteclnt file and log directory.  Users can check their private
> > logs and white- or blacklist as they wish, and even set thresholds,

> My impression is that most users don't want to bother with identifying
> and classifying spam; they just want their e-mail to work.  They'd be
> happiest if the spam filter could make all those decisions on their
> behalf.  Of course, that's impossible because only recipients can know
> if they've requested a particular message.  The other end point is to
> have users make all of the decisions.  That would be a nightmare here,
> as the majority of users wouldn't bother to check a web page.  Some
> users are also not very good at recognizing spam or phishing e-mail.
> Our compromise is a shared whitelist, to which any recipient can
> contribute.  This certainly isn't a perfect solution, but it is
> workable.
>
> > I recall being told that is not practical at U of M, but it is done
> > as some other sites.
>
> I suspect that the most common technique now is to combine DCC with a
> number of other tests, and then to deliver messages identified as spam
> to a spam folder.  I do prefer the SMTP-level rejection that DCC does.

That position is self-contradictory as well as in conflict with
well established facts of what I guess are called human factors.

The contradiction is between "the majority of users wouldn't bother to
check a web page" and "the most common technique is to" ... "deliver
messages identified as spam to a spam folder."  The spam folder web
pages of the major mailbox providers exist because all users want to
poke through their spam some of the time.  Everyone wants spam filters
to just do the right thing automagically, but everyone fears not receiving
that Amazon order confirmation.  People like to audit their spam folders
even when the filters do the right things.

The human factors issue is that people need feel that they are in
charge.  The wise human interface designer provides knobs and buttons
even if the knobs and buttons have no significant effects.

Sign up for a free account at Hotmail, send it some email, and see what
happens.  If your results are like mine for the last year or two, to
receive mail at Hotmail from a new or rare sender, you will be forced
to "bother to check a web page" (with or without SPF).  I think the
default should be closer to just doing the right thing (as Gmail seems
to do), but maybe address book filtering is the best Microsoft can do.
People must like it, because Hotmail still has millions of users.

As for being good at recognizing spam and phishing, no one is very good
at that.  It is impossible in general to know whether copies of carefully
personalized advertisement were also sent to 30,000,000 of your closest
friends only by reading the text.  People today are prone to deciding
mail is unsolicited and bulk when it is not, but a false positive is
also a failure at recognizing spam.  You can't always recognize phishing,
because big companies still send bulk mail that is indistinguishable
from phishing.  It is insane to think that you cannot be fooled; the
only tolerable defense against phishing is to assume that anything that
might be phishing is, even if it appears to come from where it should
and appears to have the right digital signatures.


You'd be surprised at what your users could do and would want to do if
you'd let them.  Providing per-user whitelists and filtering settings
does not preclude good global defaults.  Dccm uses the global settings
when the per-user settings do not give a black or white answer on each
message.  You could maintaining your common tests while letting individual
users override your choices.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.