>> We greylist after the end of DATA. This wastes bandwidth, but lets us >> use the Subject: line as an additional mix in the greylisting tuple. >> This catches ratware that retries in the face of greylisting, but >> mutates the subject line with each retry.
> We use grey listing on our low volume server, and as others have > noted, it works well because a high percentage of spam bots do > not bother to retry. But as others have mentioned, it can be > painful waiting for the delayed confirmation on a registration to a web > site to come in an hour/two later, or email from a new client > who is waiting on a response. Using dnswl.org to whitelist against greylisting might help some. > Since this is a Spam Assassin list: Is there a way of disabling > grey listing, but still receiving some benefit from the principle > that mail received from a first time or infrequent sender should > be looked upon with some suspicion? > > Assume that either some to-be-implemented SA filter, or some > mail gateway front-end (like MIMEDefang), adds a new tag/two, > for example: SENDER_FIRST_RCPT, SENDER_LOW_FREQ, > SENDER_HI_FREQ, or SENDER_HI_AVE_SA_SCORE? All these tags > might be based upon some look back period (say: 90 days). > > Theoretically, these new tags could be calculated after the fact > when passing through a spam corpus. And since many/most grey > listing systems differentiate by some form of (sender, recipient) > pairing this analysis can be reliably/repeatably performed by an > SA plug-in at the point of delivery to the user, if needed. > > It would need to be shown that these new tags improve > the ability to discriminate spam from ham. If the scheme > worked well, there might be no need for grey listing at all. >
