[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: We need an IETF BCP for GREY LISTING
I agree structure = good, but in this case what is the endgame? What's the value? What would you do with the information if MTAs returned it?
> -----Original Message-----
> From: owner-ietf-smtp@xxxxxxxxxxxx [mailto:owner-ietf-
> smtp@xxxxxxxxxxxx] On Behalf Of Hector
> Sent: Tuesday, October 11, 2011 8:40 AM
> To: ietf-smtp@xxxxxxx
> Subject: Re: We need an IETF BCP for GREY LISTING
> 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
> But the BCP can also touch based with current methods in implementing
> Greylist, with recommendations, etc.
> 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@xxxxxxxxx>
> > To: "ietf-smtp@xxxxxxx" <ietf-smtp@xxxxxxx>
> > 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@xxxxxxxx]
> > 451 T=[user@xxxxxxxxxx]
> > 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?