That might be the "ideal" but it will be more complex (bigger effort).
The problem with basing it on extended reply codes (RFC2034) that it
would mean the server itself will need to support it and also
advertise it. It may implement greylisting and not support extended
reply codes, nor the client support it.
I think we need something for Greylist that does not require RFC2034,
but a GreyList "response format" that can be parse because today, I
don't think there is any "official standard" consideration for parsing
the text part of the greylist response. You see the attempts at
layman "english" strings but no structure to it and I think that is
probably the best one can get - some structure.
But the BCP can also touch based with current methods in implementing
Greylist, with recommendations, etc.
--
HLS
Rosenwald, Jordan wrote:
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
Folks,
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]
451-HELO=[xxx.xxxxx.com] F=[xxx(_at_)xxxx(_dot_)com]
451 T=[user(_at_)xxxxxx(_dot_)com]
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.
Comments?