[Top] [All Lists]

Re: We need an IETF BCP for GREY LISTING

2011-10-11 19:45:50


Actually, both sides benefits - The client now can better schedule its queued attempts for accepted sessions and not wasting multiple attempts on GL servers with *increasingly* unexpected, and IMV, unreasonable longer delays and the GL server will see less wasted connected sessions they will be blocking anyway, thus increasing their availability for better mail acceptability.

If a BCP is widely supported, we should see it contribute to lower DNS and SMTP wasted overhead.

In addition, it will MAY reduce the growing consideration to revisit queuing strategies to consider the more complex Queue-By-MX/IP and not just Queue-By-Email-Domain, which is part of the ordeal we are going through with the much higher transaction results seen with GL servers.

Consider, for a bulk mail trade-based newsletter business, many of the target email domains with different domains are being served by a remote MX service. So for example, if among the large mailing list there are 100 email different domains but they all hosted by a single company, once they begin implementing GL, all those queued by domains attempts will fail the first time.

And that all fine and the system has worked, until there is some unexpected delay algorithm being used and your wasted attempts:

       2nd attempt 5 mins later
       3rd attempt 15 mins later
       4rd attempt 30 mins later
       5rd attempt 60 mins later

and perhaps as in some cases, much later even as long as a day later, are all wasted attempts before it is finally accepted.

To add to this, even if if the client is using a connection sharing feature, perhaps limiting four transactions per session, you have 25 groups that are greylisted. Less pain, but still a pain.

If there was some structure GL response, such as (suggestion only):

   4xx [extended-code] GREYLIST=V1 [ID=sess-id] RETRY=retry-time


extended-code optional extended code for RFC2034 compliant servers
   GREYLIST=V1        BCP anchor for the structure format
   ID=sess-id         optional unique session-id the client can use
   RETRY=retry-time   server suggested time factor to reschedule


   sess-id            is opaque with no defined format, but maybe a
                      limited in size.

   retry-time         format can be of two forms:

                      yyyymmdd.hhmmss    GMT time stamp to try again
                      hhmmss             blocking time

But either form is fine since its:

    yyymmdd.hhmmss = current datetime + hhmmss

I just indicated the RETRY=hhmmss format because GL setups already have a "blocking time before acceptance" field concept as part of their setup.


Keith Moore wrote:
I think the only real value in this extension would be to reward clients that recognize it, by providing their users with more predictable service (=less delay, more uniform delay).


On Oct 11, 2011, at 2:16 PM, Murray S. Kucherawy wrote:

RFC3339 instead of ISO8601, perhaps?
Of course, abusers will only pay attention to this if it benefits them and it�s cheap to do so. But they won�t be distinguishable from legitimate clients that just don�t know about this extension and retry by their own schedules, so one can�t penalize such clients for not respecting the request. On the other hand, you might be able to identify �good� clients (for some value thereof) by observing which ones do respect the request. From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Keith Moore
Sent: Tuesday, October 11, 2011 11:06 AM
To: Steve Atkins
Cc: SMTP Interest Group
Subject: Re: We need an IETF BCP for GREY LISTING
On Oct 11, 2011, at 1:45 PM, Steve Atkins wrote:

In that case, some minor extension to allow the SMTP server to communicate something a 
bit more nuanced than "Go away, come back later." might have some value.
I could see value in that. I could imagine an SMTP extension which, if included, indicated that the server might send a response of the form 4xx please retry between <date-time>-<date-time> response to say the MAIL (or maybe DATA) command, where <date-time> could be an ISO8601 date-time (the horror!) based on GMT (Z) and with no punctuation. If the client included a SIZE the server could even do bandwidth reservation. Of course there would be no guarantee that the second attempt wouldn't result in some sort of 4xx response for other reasons. Greylisting servers could certainly make use of it, though I don't know if it would be a good idea to recommend that greylisting servers use it. Keith