Re: We need an IETF BCP for GREY LISTING

+1

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

where

   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

where

   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.

--
HLS


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).
> Keith
>
> 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>
> >  
> > ...in 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
> >