Mailing List Message #92361
From: Jeff Wark <>
Subject: Re: Feature request: temporary greylist
Date: Tue, 28 Aug 2007 12:02:32 -0400
To: CommuniGate Pro Discussions <>
X-Mailer: CommuniGate Pro WebUser v5.0.13
I like the idea.  Not true greylisting, but a separate list from temp blacklisting that produces a temporary rejection [4xx] instead of a permanent one [5xx].  I believe a lot of the major providers do that since I quite often see temp rejecting my queues to them.

On Tue, 28 Aug 2007 08:54:58 -0700
 "Bret Miller" <> wrote:
How does someone get on the greylist?

CLI function and/or rule action initially. Perhaps in the future such a feature could be added to the rate-limiting feature. If a host exceeded the rate limit in SMTP > Receiving and wasn't in a whitelist, it could get added to the greylist.

My understanding of greylisting was that if the to/from/ip triple had not been seen before, there would be a delay of a few hours.

Indeed true greylisting requires much more work to implement that what I am suggesting, and it would be a welcome feature too.

What I am suggesting is implementing a way to temporarily reject email from certain hosts based on criteria the mail admin decides is relevant. We would use rule action and/or CLI to add Ips to a temporary list (like the temporary blacklist now), and CGPro would issue a 4xx reject for the message rather than the 5xx reject on the blacklist. This allows the message to be retried at a later time (unless it's from a spam bot in which case it likely won't be retried). Issuing a 4xx reject doesn't tie up resources on your server, but it also doesn't tie up resources on the sending computer either. But it does delay the message, which is the point of this action.

So, with that [perhaps incorrect] understanding your features might be:

1) CLI functions to Add, Remove, and enumerate
Add would pre-add a triple to the list, pre-allowing it to send email without delay or a reduced delay
Remove would remove a triple from the list, making it unknown to the server and therefore forcing it to wait the whole delay period enumerate - same.

I would like Add, remove and enumerate, but I would settle for a like implementation of temp blacklist where we have only get and set as long as "set" didn't reset the expiration time of hosts already on the list.

I'm only talking about adding the host IP to a list here-- nothing more.

2) If an IP doesn't exist in the temp greylist OR it does exist in the temp greylist but has not been delayed enough, issue a 4xx rejection.

No. This would be true for real greylisting. I just want a temporary greylist where I can say "issue a 4xx rejection for these hosts for a while".

3) Provide a method of time-expiring the greylist entries....same as before.

Time-expiring like the current temporary blacklist does.

A true greylist implementation would be appreciated too. But I realize that takes a lot of effort and I'm willing to settle for a limited list for temporary rejection-- like a temporary blacklist but not quite as black.

How could I use this?

As a method for controlling spam or worm flow. A message comes into my server not blacklisted, goes through SpamAssassin, gets a 20 score meaning most certainly it's spam, or goes through ClamAV and gets flagged as a virus. My filter uses CLI (or a subsequent rule uses AddToTempGreylist action) to add the host to the temporary grey list. The next connect from this same host gets an immediate 4xx rejection so the flow of spam or virus is interrupted from that host. Hopefully the software isn't smart enough to retry or doesn't want to wait and retry so the message is simply discarded and never sent to my server.

I'm sure you can come up with other reasons to delay email from certain hosts.

This implementation is very similar to the temp blacklist, so IMO, it wouldn't be hard for Stalker to add and would give us a little more control over the SMTP session. Right now, we have little control over the session. We can run all our server-wide rules after the message is send and before it's accepted, or they all run after the message is accepted. Even at that, you only get the choice to accept, reject 5xx or discard. I want a way to say "I don't like you, try again later".


Again, this is based on my assumption of what greylisting is.

On Tue, 28 Aug 2007 07:01:01 -0700
  "Bret Miller" <> wrote:
>> I think this has been requested before, but I'm going to do it again. Grey listing is being done more often, even by big >>servers like Yahoo and MSN/Hotmail as a method of reducing spam. Essentially the theory goes like this: we received spam from >>you, so we are now going to delay your email for a certain length of time. For many spammers, this is enough for them to give up >>delivering the spam.
>> >> I think this would be an easy feature to add to CGPro because it essentially already exists. The temporary blacklist works >>pretty much like a greylist would except it uses a 5xx rejection code instead of a 4xx code.
>> >> Here's how this feature would work in CGPro:
>> >> 1. Provide CLI functions to add, remove, and enumerate the temporary greylist.
>> >> 2. If an IP exists on the temp greylist, issue a 4xx rejection for the message before the data phase.
>> >> 3. Provide a method of time-expiring the greylist entries, and settings that control the length of time IPs remain on the list.
>> >> 4. (Optional) provide a rule action to "Add to greylist" so that admins could add IPs to the greylist based on results from >>external helpers.
>> >> Thanks,
>> Bret

This message is sent to you because you are subscribed to
 the mailing list <>.
To unsubscribe, E-mail to: <>
To switch to the DIGEST mode, E-mail to <>
To switch to the INDEX mode, E-mail to <>
Send administrative queries to  <>

Jeff Wark
TBayTel Internet
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster