ietf-smtp
[Top] [All Lists]

RE: We need an IETF BCP for GREY LISTING

2011-10-11 08:21:57

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(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Hector
Sent: Tuesday, October 11, 2011 8:40 AM
To: ietf-smtp(_at_)imc(_dot_)org
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
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?