Dwight,

Dwight,

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.

Per RFC2821, when there are multiple MX records, the sender MUST try sending an email to all servers in the list if one is unavailable. This would mean that if an attempt is made to the primary MX server, and this fails due to the graylisting, the remote server should then immediately try connecting to the secondary server. The relevant section of the RFC is:

   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.

Now, this process will fail for the first attemp due to the greylisting. The same RFC2821 now states that the sender MUST retry a particular destination if the first attempt has failed. This means that the remote server MUST retry sending the email to the primary MX server. if you see servers that are not being able to deliver mail to you in your configuration, it's very likely that they are violating this RFC, which is considered the RFC when it relates to emails. The relevant section here is:

   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?

Dan, I have to correct you on this one. Each SpamFilter uses its own copy of the greylist file, and that file is only imported once when SpamFilter startup. Unlike all other configuration files, this one is not reloaded by SpamFilter if modified externally.

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

WebGuyz, using the full triplet would be potentially a disaster waiting to happen in large installations. If, in addition to keeping track of individual IPs, we also kept track of the to/from email addresses for all emails regarding that IP, the number of entries in the list would row exponentially, going from the millions of entries you will be reaching now, to the billions. SpamFilter is efficient, but that may be too much for a dinky 3MB executable!

Desperado wrote: Roberto,   I was refering to the single file in the SFE configurating which I thought was shared by ALL domains under that same SFE instance.  Am I wrong there?  I did not mean that the file itself could be shared by differant servers instances.

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.

LogSat wrote: WebGuyz, using the full triplet would be potentially a disaster waiting to happen in large installations. If, in addition to keeping track of individual IPs, we also kept track of the to/from email addresses for all emails regarding that IP, the number of entries in the list would row exponentially, going from the millions of entries you will be reaching now, to the billions. SpamFilter is efficient, but that may be too much for a dinky 3MB executable!

Webguyz,

The proxy will have to proxy the connection to keep all the connection information. (so all other tests based on the ip address can be performed)

My solution was with a NATting firewall.

I still have a firewall in front of the SF boxes but it now does just the blocking based on the limbo information.

Dont know how this can be done in windows.

The rules are quiet simple.
if ip in limbo drop
if ip in greylistok forward to another ip

I can share my firewall script if someone is willing to implement it in windows.

 

 

Originally posted by Desperado Roberto,   I was referring to the single file in the SFE configurating which I thought was shared by ALL domains under that same SFE instance.  Am I wrong there?  I did not mean that the file itself could be shared by differant servers instances.

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?

Roberto,
How about an option for the admin to decide  the interval when to flush the greylist to the db. and how often it should be reloaded.
I think a "select ip from table where id>max_id_we_have" every 10 minutes will not be so resource intensive.

sysiq, can you please let us know what build of SpamFilter you are using?

A little question:

On SFE the Grey Listing could be apllied to all domains or you can choose wich one use and wich one will not?

Reading your post it seems the first option the right one, but will the second be possible in the future?

Thank you,
Simone

Edited by WebGuyz - 24 January 2008 at 9:40am