What to do about brief text messages with misspelling?

Gary Mills mills@cc.umanitoba.ca
Tue Jul 8 22:42:30 UTC 2008

On Tue, Jul 08, 2008 at 04:33:40PM +0000, Vernon Schryver wrote:
> > From: "John Levine" <johnl@iecc.com>
> > To: "Gary Mills" <mills@cc.umanitoba.ca>
> > > I had a complaint the other day from one of our users who is receiving
> > > many stock pump spam messages.
> > > What else can we do about this spam?  The sending computers are all
> > > listed on the PBL, which we don't currently use.  Is this our only
> > > hope?  I'm reluctant to use that blocklist because we have clients on
> > > networks that are listed there.  Using it would force clients to use
> > > authentication to send e-mail, generating complaints from legitimate
> > > users.  Yes, we may even have legitimate users in Peru and Viet Nam.
> >
> > I'd bite the bullet, use the PBL, and get your Asian clients to fix their 
> > configurations.  It's one time pain for long term benefit all around.
> I agree with John, but a compromise might be to whitelist those clients
> instead of getting them to change their configurations to use some
> form of SMTP authentication.  Whitelisting might require more work on
> the SMTP server side, but little or no work by the client.

Except that I want the users to do the work, not me.  They'll complain
to our Help Desk, but they won't be able to whitelist their own IP
addresses.  Still, we may have to do this.

> If they can be whitelisted by IP address, perhaps their addresses
> should not be in the PBL.  On the other hand, if their IP addresses
> should be in the PBL, then either they are violating the terms and
> conditions of their ISPs or they are likely sources of spam.

Our local ISPs have all blocked the SMTP port.  To send e-mail through
our e-mail server, users have to connect to the client port.  Sendmail
forces them to authenticate on that port.  This automatically
whitelists their IP address.  So, that should all be okay.  That leaves
users at other locations that don't authenticate, a small minority, and
legitimate e-mail servers that are on PBL networks.  I trust that the
latter are also small in number.  Maybe this will work after all.

> There is another possibility.  I've long wondered about changing the
> DCC client code support for DNS blacklists to have two sets of blacklists.
> Individual users can enable or disable DNSBL checks for their mail done
> by dccm, dccifd, or dccproc.  If there were two sets with separate controls,
> you could put the PBL into the second set and let that user enable it
> for only that mailbox.  Would adding that complication be worthwhile?

That won't work here because we use a single shared whitelist, to
which all users contribute.  That's because most users don't want to
do the tedious work of whitelisting messages; they just want the spam
to stop.  Yes, there is quite a range of users in terms of spam
control.  Some want fine control.  Some want a `spam folder' where
they can look for missing messages.  Some want us to do all the work.
I'm hoping that our system at least satisfies the majority.  Users
certainly are impressed when they look at the list of spam addressed
to them that was automatically rejected by DCC.

-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-

More information about the DCC mailing list

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