I might be missing your point, so correct me if I am, but it sounds like a BCP
for extended response codes more than a position/policy/BCP for greylisting.
----- Reply message -----
From: "Hector" <sant9442(_at_)gmail(_dot_)com>
To: "ietf-smtp(_at_)imc(_dot_)org" <ietf-smtp(_at_)imc(_dot_)org>
Subject: We need an IETF BCP for GREY LISTING
Date: Tue, Oct 11, 2011 7:47 am
According to my statistic, this year marks a massive growth in SMTP
receiver implementing greylisting to the point that some systems are
becoming more "elaborate" with their responses, including multi-line
response such as this as a response to the DATA EOD response:
451-DEFER - TB3 - Try a lower numbered MX record - S=1 FakeMX - FAKE-MX
451-I=[xxx.xxx.xxx.xxx] X=tarbaby H=xxx.xxxxx.com [xxx.xxx.xxx.x]
More so, the delays requires to retry vary greatly and sometimes it
seems like it can a day.
I think we finally need an official IETF "BCP" written up to begin
maybe coordinate the client/server operation to help to alleviate the
increasing delays and wasted retries to the point where i am now
hearing complaints with the ATTEMPTS are exhausted and the destination
is "flagged" as bad domain or address.
One suggestion for the GREYLIST "BCP" is if a receiver is going to
block for an extensive time, it should maybe provide that feedback in
should official response format.
For use, our stock retry attempt table has initial 5, 10, 15, 30
minutes delays before it fall backs to 1 hour for the remaining
attempts up to 4 days.
Greylisting has become essentially a "pseudo" standard today and too
many systems are becoming too aggressive with delays. This needs to
be coordinated better.
I think someone should take up the effort to begin/draft an GreyList
BCP for systems to follow.