Re: We need an IETF BCP for GREY LISTING

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?
--
HLS