[Top] [All Lists]

Re: We need an IETF BCP for GREY LISTING

2011-10-11 09:06:47

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?

Best Regards,

-- Tim

----- Original Message ----- From: "Hector" <sant9442(_at_)gmail(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
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 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=[] X=tarbaby []
451-HELO=[] 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.


<Prev in Thread] Current Thread [Next in Thread>