On 11/29/12 14:46:25, David F. Skoll wrote: > 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. 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.
