Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04

["Murray S. Kucherawy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of John Levine
> Sent: Friday, February 17, 2012 8:29 PM
> To: [e-mail]
> Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04
> 
> Looks pretty good.  A few minor points:
> 
> In section 3, I think that you should point out that a in a successful
> greylister, all the regular correspondents will be whitelisted, so the
> only mail that is delayed is mail from an IP that has never sent mail
> before, or sent mail so long ago that it's fallen out of the whitelist.
> In mail systems I've used, the vast majority of mail comes from places
> on the whitelist, so after a training period (which you can fake by
> watching traffic before you turn on the greylister and seed the
> whitelist with all the addresses you've seen) only a small proportion
> of mail should be affected.

I've added this paragraph to the bottom of Section 3:

   Presuming that known friendly senders will be manually configured as
   exceptions to the greylisting check, a steady state will eventually
   be reached wherein the only mail that is delayed is mail from an IP
   address that has never sent mail before.  Experience suggests that
   the, the vast majority of mail comes from places on such a developed
   exception list, so after a training period, only a small proportion
   of mail is actually affected.  The training period could be replaced
   by processing a history of email traffic and adding the IP addresses
   from which most traffic arrives to the exception list.

Does that cover it?

> In section 3 and again in section 9.2, it refers to the size of the
> database.  My total database is under 40,000 entries, including 92
> IPv6 addresses.  I expect a larger system would have a larger database,
> but it would be a pretty feeble server that would have trouble with a
> table even ten times that size.  My manual whitelist has 62 entries,
> mostly CIDR ranges, probably half of which are stale but there's not
> much incentive to clean it out.

Added this to the end of 9.2, same question:

   In practice, this has not appeared as a serious concern, because any
   reasonable aging policy successfully moderates database growth.  It
   is nevertheless identified here as a consideration as there may be
   implementations in some environments where this is indeed an issue.