[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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