Keith Moore wrote:
On Oct 11, 2011, at 7:43 AM, Hector wrote:
I think someone should take up the effort to begin/draft an GreyList
BCP for systems to follow.
Comments?
I'm not sure that it's worth the trouble. The whole point of greylisting
is to marginalize naive client implementations on the assumption (largely valid
to this point) that they're likely to be spambots. But I expect that
spambots will start to deal with greylisting very soon. If IETF were to
document greylisting it would only accelerate that process.
IMO, I think that is good because the main logic behind GL is that
clients are expected to retry and IMO, it works because legacy Bad
Guys will never adapt anyway, regardless of what you do. These are
the ones GL tries to get and its most effective against. We don't
want to hurt anyone else - even if you are a "spammer" - the rule is
simple - use a Standard SMTP expectation for retrying.
The problem is that everyone is now doing it and in varying ways to
delay you. Now you need smarter Retry Attempts table at the DOMAIN
level but you won't have that information until after the fact.
What I am finding are a few new basic issues this year
- More greylisting even at the BUSINESS and CORPORATE level,
- Longer delays
- "False positive" bad domain flagging of exhausted attempts
The latter is what was presented to me, however, in this case, the
customer got a bounce after the total retry attempts and stated he
never had a problem before sending to this remote host. It appeared
the remote implemented Greylisting. We took the original archived
message, forced a retry and PUFF - it was accepted. That was 1 day
later - Go Figure! Looking at the logs, there were similar sessions
traces where it took nearly a day before it was accepted.
That is ridiculous in my book.
--
HLS