Re: [Exim] variation on dns blacklists

Pàgina inicial
Delete this message
Reply to this message
Autor: James P. Roberts
Data:  
A: Exim users list
CC: Dr Andrew C Aitchison, Alan J. Flavell
Assumpte: Re: [Exim] variation on dns blacklists
----- Original Message -----
From: "Alan J. Flavell" <a.flavell@???>

> On Mon, 12 Jan 2004, Dr Andrew C Aitchison wrote:
>
> > Worse, if you run exiscan, any mail you reject for this user will
> > turn into a *bounce* from the forwarding service, and you may find
> > that innocent third parties receive spam or viruses intended for
> > that user.
>
> True enough, but that's under *their* responsibility, not yours.


In the system I am using, we restrict this method (detecting IP of host that
sent message via some particular forwarder), to a specific set of known
forwarders.

Furthermore, the mail is not rejected or blocked, but instead, diverted to a
spam-holding account, where we can recover false positives, if a complaint
should ever arise. It will also be a prime source of spam, should we decide
to ever implement a Bayesian filter. ;)

There are a lot of "email forwarding for life" services provided by colleges
and universities, and I suspect the number of these will grow over time.

The institutions that provide these services tend to *not* do any filtering.
It is a deliberate decision, based on the idea that even one false positive is
too many, for such a service.

I believe, given their large number of very diverse customers, that they are
correct in this approach. As a customer of such a service, I am happy to know
that they are not blocking anything, since I can then sort through and block
what I want on my end, or not. (Exactly the same idea as "let the end-user do
the filtering with their MUA" and the "I want to sort my own snail mail, not
let the postman do it for me.")

>
> If everyone else tries to hide their problem, they'll have no motive
> to stop accepting and forwarding bad mail.


Define "bad mail" with 100% precision that all customers can agree on.

Now imagine you are a prestigious university, and you know perfectly well
there is a high probability that at least some of your clients may be
researchers who are studying spam in great academic detail! Perhaps some of
them are using their account to collect spam to prime their own Bayesian
filters for their "real" email account... Imagine any of a 1,000 such
scenarios. And ask the question again...

>And the only other ways of
> shielding users from harmful or nuisance mail would seem to be
> blackholing (which hardly makes for a reliable email system!) or
> laundering (which brings its own disadvantages in terms of downstream
> recognition).
>
> IMHO and YMMV, for sure.
>


Well, there is also the option I am using, which is to divert the mail to a
spam-holding account. There is no bounce. It does not appear in the user's
inbox. And, if a user comes to me and says "Hey, sender xyz sent me an email
last Tuesday, and I never got it," at least I've got someplace to look for it.

For normal RBL blocks, done at SMTP time, if a false positive occurs, the
sender is alerted and can take steps to correct the problem.

In this special case, applying RBLs to forwarded emails, from certain known
forwarders, we cannot risk sending bounces, for the simple reason that we
don't want to generate lots of "collateral spam" to innocent 3rd parties. We
also don't want to piss off the generous institution(s) providing the free
forwarding service(s). ;)

The vast bulk of emails caught this way are going to be true spam, and I'd
love to just blackhole them. But, since I can't alert the sender, I feel
obligated to keep the mail around for a little while, just in case.

My preferred solution would be to migrate to a different mail box format, so I
can divert the email to each customer's "spam" folder, and let *them* do any
looking for false positives. This will work nicely with IMAP service, I
think.

Any suggestions for the correct mailbox format to use for this approach? I'm
still using the default (all messages appended into one file for each user),
which does not support individual folders like this, AFAIK.

Jim Roberts
Punster Productions, Inc.