[Top] [All Lists]

Re: We need an IETF BCP for GREY LISTING

2011-10-17 12:43:01

Keith Moore wrote:

Hector responded to Keith:
hmmm, unless I mis-read people's input, many people contributing to the thread recognized there are issues and most have indicated a note that a IETF document for greylisting would be a good thing.

I believe you cited an interest in an SMTP extension for a retry hint.

I mentioned how it could be done, but also expressed concern that it might not be worth the trouble... also I said that greylisting wasn't the reason for such an extension.

GL would be among the reasons as a retry=hint proposal would apply to all 4yz reasons a remote receiver may have, which in practical terms today are receivers:

   - Implementing GreyListing
   - Applying any Connection Load Restrictions

That is the reality among many servers that can not be denied. Either 421 or 45x responses are issued and they are applied in varying ways, in other words, some will use 421 with a text response indicating a GreyListed action at the connection or as a response to MAIL FROM, RCPT or DATA.

The restrictions whether due to loading or greylisting, delays varies as well, some have very short, some have longer delays.

Personally I think writing up an RFC on greylisting will only dilute its effectiveness as a spam countermeasure.

I don't agree with this concern.

First, if one is to assume adaptation will takes place, one can not just assume only the negative adaption, but both the positive and negative. The positive adaption will provide a tremendous technical benefit in reduce traffic on the network, and also improve system availability and better throughput.

Second, what is the negative adaptation?

A bad guy learning when (time wise) to hit a server?

GL #1 benefit is addressing the "single shot" random blaster of mail when a 4yz means to TRY again with the same information, not different information.

The bad guy just needs to try again with the same information if he wanted to get around GL restriction. If he can't do that, a retry=hint will not going to get him in any shape of form.

But when about the spammer who does try again? Well, GL allows it as long as its done within after the blocking time.

If the spammer adapts to the retry hint, not only does it help him, it also helps the server by reducing the rejection overhead. For us, even with a 55 second blocking time, many spammers will redundantly retry 3-4 or more times within 55 seconds before its finally accepted. If they adapted to the retry=hint, that equal a tremendous amount of overhead rejection on both ends.

So I see no negatives at all here.

Can you describe how the GL effectiveness is diluted with a retry=hint concept?