kspare,

The botnet herds really do get stopped with the addition of the SFE version of greylisting.

Roberto, you know us end user, never happy

Amir,

I use greylisting with 2 SFE's. I thought the same thing, that there might be instances of mail not getting through, but so far (since Sunday afternoon) I have not had anyone complain.

Would be nice to share a greylist database, but the question becomes are we willing to put up with a performance penalty. And if a greylist db became a reality, I would like to see a more standard version of greylisting using triplet info.

Perfomance penalty to me means its just time to move SFE's to beefier hardware

There I go assuming things again - I thought the limbo or temporary greylist was NOT shared. 

I have a client that complained about getting bounces.  They are a mortgage company and can't afford to miss clients emails.  I did a trace and found that several of their missing emails went to our first MX record (SF) and were put in the limbo grey area.  The next email went to another MX (different SF) and it too was put into the grey limbo. So the email source saw the greylist messages and said they were being bounced.  My mortgage company never got the email from the sender.

I had the mortgage company in a separate individual configuration of SFE but since the greylist is a global configuration, I could not tweak this clients email settings.  For the time being I am just forwarding all of their email unfiltered directly to their exchange server.

I have not had complaints from other clients on the greylist.

Some "so called" IT people can't help but tweak those mail server settings.  (smile)

dcook wrote: I know we don't have an enterprise version for greylisting -- but I see we need it.  I have had several clients say they are getting bounces.  Here is what happened: 1. First email is sent to MX-10 and greylisting starts 2. Second retry email is send to MX-20 3. No more retry's - email is non-deliverable   First of all, the mail server should be more persistant trying more than twice for delivery. Second if enterprise servers shared the greylist - it would not matter.

   When the lookup succeeds, the mapping can result in a list of
   alternative delivery addresses rather than a single address, because
   of multiple MX records, multihoming, or both.  To provide reliable
   mail transmission, the SMTP client MUST be able to try (and retry)
   each of the relevant addresses in this list in order, until a
   delivery attempt succeeds.  However, there MAY also be a configurable
   limit on the number of alternate addresses that can be tried.  In any
   case, the SMTP client SHOULD try at least two addresses.

   The sender MUST delay retrying a particular destination after one
   attempt has failed.  In general, the retry interval SHOULD be at
   least 30 minutes; however, more sophisticated and variable strategies
   will be beneficial when the SMTP client can determine the reason for
   non-delivery.

Desperado wrote: Dwight,   The enterprise mode does greylist but shares a single file.  I am not seeing the same issue you are.  Can you expand on it a little?

WebGuyz wrote: Would be nice to share a greylist database, but the question becomes are we willing to put up with a performance penalty. And if a greylist db became a reality, I would like to see a more standard version of greylisting using triplet info. Perfomance penalty to me means its just time to move SFE's to beefier hardware

Misunderstood you. Yes, in this case you're absolutely correct. The file will apply to the entire SE installation, for all the domains it handles.

Each spam filter server currently keeps it own independent grey list. In our case, in this spam filter build SFE-1 and SFE-2 keep their own, separate grey list that is used globally per server. The information is never shared between SFE-1 and SFE-2.

Roberto did you say that in a future build grey list sharing for the enterprise version using the database should be supported?