[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: We need an IETF BCP for GREY LISTING
I think a BCP that outlines the advantages and disadvantages of various
timeout values can be a good thing. The most we've run for a timeout is 30
minutes but now typically run with much shorter timeouts. On the other hand
recently we have been seeing increases in spam getting through the GL so I
suspect that some might feel compelled to adjust the timeout window to
compensate. Of course making this window too large will start to have an
adverse effect on the legit sending site queues and frequency in which they
attempt a retry.
On the other hand if we're trying to standardize on GL response codes, I
don't really see the utility in this. GL's are there for one reason - to
effect a simple and cheap (something that can be done at connection time
rather than after queuing) anti-spam measure. Giving the bad guys more
information on how you are protecting yourself seems contradictory to the
primary objective. The other systems trying to communicate with you (the
good guys) likely won't bother to do anything with this additional
information anyway as they will be governed by their own internal backoff
algorithms and timing.
What am I missing here?
----- Original Message -----
From: "Hector" <sant9442@xxxxxxxxx>
Sent: Tuesday, October 11, 2011 8:39 PM
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.
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
----- 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
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.