[Top] [All Lists]

Re: greylisting done at end of headers, or end of daya (QUIT) ?

2007-01-31 17:32:19

Carl S. Gutekunst wrote:

What surprises me most, though, is that gray-listing is working for
anyone. The entire assumption behind gray-listing is that zombies don't
grok 4xx errors.

Good Guys are 100% SMTP compliant. Bad Guys are not. Thats the theory and its true.

I don't see any evidence of that; what I'm seeing now
is the zombies will slam the same identical message at you three or four

huh?  Thats is exactly what GL is suppose to stop.

Gray listing used to work pretty well for me a year ago, but I'm
pretty much ready to turn it off now, all it does is slow down
legitimate mail.

The whole trick to GL is how good is your whitelist system, including auto-whitelisting ideas, i.e. When you send email to someone you know, your GL system should auto-whitelist these people because a possible reply from these people might occur. No need to greylist them.

GL, like any other anti-spam technology is about dealing with the "unknown", the "anonymous" sender. No need for them if your system has a clue about the people sending you mail. Its about building your social/business network of friends and business associates.

But your are right, the anonymous "legitimate" transaction will be blocked.

If there anything to learn from all this, is that fact, it is a growing feature, whether we like it or not, and what can be done is a BCP that provides a enhanced guideline for "retry logic."

For example, prior to implementing GREYLISTING into our SMTP mail system, we had a default 1 hour retry, 72 attempts (3 days) before a bounce is created. When we implemented GREYLISTED, we quickly learned that we needed a flexible retry table. This our default now:

# WCSMTP retry frequencies (in minutes)

So the 1st and 2nd attempt is tried in 5 minutes. This helped our customers who were hitting Greylist servers get their mail delivered.

We probably need some BCP or wording in RFC 2821bis regarding the reality of today.