Re: [anti-spam-wg] greylisting (was: RIPE 51 anti-spam WG minutes)

[Markus Stumpf <]

On Wed, Dec 07, 2005 at 04:16:44PM +0000, Rodney Tillotson wrote:
> Peter Koch: Greylisting is pushing the problem towards the
> infrastructure. If I have a high-volume mail server, lots of mail
> does not get delivered on time and puts burden on the sender side.

IMHO infrastructure is the wrong word here. Sender is the better term.
And isn't antispam all about making every mail harder and more cost intensive
for the sender (and thus even more for the spammer)?

And: greylisting isn't greylisting.
We use kinda sliding window ... if a triple gets whitelisted it will
stay in this state for 32 days. Another use of this triple within this
timeframe renews the timeframe to 32 days.
We also use scripts to inspect the database to locate legitimate
mailservers and add them to a whitelist.
We also use MTAMARK to disable greylisting for hosts with a "1" mark
(quite a lot of german mail service providers are using MTAMARK already).
We are rejecting about 87.5% of all (total) incoming messages permanently
(they never come back) with greylisting. With the whitelist we can keep the
greylist to autowhitelist messages at around 15-20% of all accepted messages.

For viruses and worms greylisting works exceptionally great. The
virusscanners for all customers with greylisting very rarely see any
of the current huge W32/Sober-Z wave or any other viruses.

And handling whitelists would be really *MUCH* easier if DNS admins weren't
so stupid and weren't breaking RtoL hierarchy all the time:
What is the big deal putting in the PTR like
    h1102.out.mm-retail.amazon.com
    h1103.out.mm-retail.amazon.com
    h1104.out.mm-retail.amazon.com
which could be whitelisted with
    *.out.mm-retail.amazon.com
instead of
    mm-retail-out-1102.amazon.com
    mm-retail-out-1103.amazon.com
    mm-retail-out-1104.amazon.com

Same for
    smtp-outbound.nix.paypal.com
    smtp1.nix.paypal.com
    outbound1.den.paypal.com
    outbound2.den.paypal.com
and
    data.ebay.com
    lore.ebay.com
    mxpool05.ebay.com ... mxpool23.ebay.com
    mxsmfpool02.ebay.com ... mxsmfpool24.ebay.com
	why not pool[0-9][0-9].mx.ebay.com
	why not smfpool[0-9][0-9].mx.ebay.com
    outbound4.ebay.com
    camppool06.emailebay.com
    smfcamppool05.emailebay.com
    smfcamppool09.emailebay.com
or
    nproxy.gmail.com
    uproxy.gmail.com
    wproxy.gmail.com
    xproxy.gmail.com
    zproxy.gmail.com
      why not [a-z].proxy.gmail.com
There are zillions of examples for that with bigger mail installations.

I am not talking about small companies with one or two mailservers,
but "the bigger ones" should IMHO be aware of the problems of spam,
black/whitelists and getting mail through. So why do they make it so
hard for all the others and last but not least themselves.

But I do see a problem if greylisting gets wide adoption. Spamware will
not keep track of 2xx, 4xx or 5xx codes as it does now. Spamware will
"respam" each and every message again after - hmmm - 1 hour. This will
break the greylisters and will become really annoying to non-greylist
mailservers.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"