Re: [exim] More embedded Perl functionality

On Wed, 2004-11-03 at 18:25 +0530, Suresh Ramasubramanian wrote:
> Frankly, speaking as the postmaster of a very busy site (~ 40 million users)
> I would much rather prefer that people *not* do graylisting, or callbacks..
> all this does is stuff our queues up with unnecessarily delayed email, and
> increase the number of smtp connections to our MXs, especially when someone
> forges one of our domains into a dictionary attack and spams a callback using
> site.

I do see the issue with callbacks/DDoS. That's a different can of
worms.

I still maintain that greylisting will have little impact on your
servers, unless your outgoing mail persistently goes "new" recipients (a
trait that often characterizes spamming hosts).


> Dave Crocker's BATV and CSV proposals sound like just what we have been
> looking for, by the way ..

These are interesting and promising proposals, BUT:

- BATV, like so many other schemes (e.g. micropayment schemes,
Yahoo! sender IDs, etc) require changes in the mail infrastructure
(i.e. participation by both sender and recipient) to be effective.
With so many different Envelope Sender signature/cookie schemes out
there, it will be a challenge to get everyone to speak the same
"language", so to speak.

- CSV, aside from the above, also is useful only for accepting mail
that would otherwise be rejected. It is trivial for a spammer
to HELO with a name for which no DNS "SRV" records exist - and you
have gained nothing.

Also, nothing stops spammers from implementing CSV - so you may
want to do spam filtering even on messages that are delivered in
a CSV-compliant fashion. (A case in point - Rumors have it that a
higher percentage of spammers than legitimate sites incorporate
SPF/SRS).


> > This, too, can be supported per-user, without restricting each mail to
> > one recipient. See the links above for details.
>
> This is broken, RFC wise.. and an irritating characteristic of some mail
> gateways that allow per user filtering of email (such as messagewall)

We were here talking about user-specific _whitelists_, i.e. hosts for
which no filtering will occur. In a way, it is the opposite of per-user
filtering.

-tor