Spam Filter ISP Support Forum

  New Posts New Posts RSS Feed - Greylist feature request
  FAQ FAQ  Forum Search   Register Register  Login Login

Greylist feature request

 Post Reply Post Reply
Author
StevenJohns View Drop Down
Senior Member
Senior Member


Joined: 03 August 2006
Status: Offline
Points: 119
Post Options Post Options   Thanks (0) Thanks(0)   Quote StevenJohns Quote  Post ReplyReply Direct Link To This Post Topic: Greylist feature request
    Posted: 08 February 2008 at 4:27am
Roberto,
 
I have been using SF for ages now and love it, especially te greylisting which works really well. However, I have a few clients who keep reporting that they are missing emails from suppliers that they should be getting (namely from Tesco, the largest supermarket in the UK). I have checked in the logs and can't see any mention of these emails, but obviously I can see lots of disconnects due to the greylisting.
 
My understanding of your implementation is that when an SMTP server connects to SF, then SF checks the "Greylist limbo" and "Greylist Allowed" lists. If the IP is not in the allowed list, it is added to the limbo list and the connection is dropped with a 400 temporary error.  This is fine, but gives us no clue in the logs as to who attempted to send the email.
 
My suggestion is that you delay the 400 response (and the disconnect) until after the sender has sent the "mail from:". Doing this would have exactly the same results as we currently have, but with the added advantage of having the sender's email address written in the logs so that we can track down apparent missing emails.
 
I can't see any adverse effects of delaying the 400 response, but please let me know if I have missed anything relevant.
 
Cheers
Back to Top
StevenJohns View Drop Down
Senior Member
Senior Member


Joined: 03 August 2006
Status: Offline
Points: 119
Post Options Post Options   Thanks (0) Thanks(0)   Quote StevenJohns Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 4:31am
Just thought, actually you could delay the 400 temp error and disconnect until after the RCPT command, this way we can see bothe the sender and the intended recipient is...
 
This would make tracking down missing emails so much easier.
Back to Top
Simone View Drop Down
Groupie
Groupie


Joined: 06 July 2005
Status: Offline
Points: 42
Post Options Post Options   Thanks (0) Thanks(0)   Quote Simone Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 6:26am
If SF will do that it will be easier to implement the option to disable this feature to some domains that want to be unfiltered from the Greylisting and limbo cache.... i have some problems using global filters because if only one customer does not want it i have to disable it to everybody.

I cannot understand why i cannot disable SFDC on a single domain.

I'm Using SFI ... SFE ca do that?
Back to Top
StevenJohns View Drop Down
Senior Member
Senior Member


Joined: 03 August 2006
Status: Offline
Points: 119
Post Options Post Options   Thanks (0) Thanks(0)   Quote StevenJohns Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 7:10am
Simone,
 
I don't think you understood properly what I was asking for.
 
I do not want to stop greylisting at all, it works fine.
However, in the current version, when a connection is made that is not in the allowed list, SF will drop the connection immediately. This gives the issue that we do not have any information in the logs as to who the potential email was from and who it was to.
 
My suggestion was to simply delay the 400 response until after the RCPT command so that we have the sender and recipient in the logs and the greylisting should then carry on as it currently does.
 
 
 
Back to Top
Simone View Drop Down
Groupie
Groupie


Joined: 06 July 2005
Status: Offline
Points: 42
Post Options Post Options   Thanks (0) Thanks(0)   Quote Simone Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 10:08am
Roberto in another post (or email maybe) told me that Greylisting and ip limbo black list catch only the IP and nothing else, so it not possible to decide which domain should use Grey listing and which one not in the domain filter matrix ad u can actually do with SUBL, MAPS, etc.

You are asking SF to catch EmailFrom data for logging purpose so if SF will catch it, it will also ave the possibility to decide which domain has this filter and which one not because it catch also the DomainFrom data.

My problem is that some customer of mine wuold like to receive ALL spam ... i don't why but they prefer it instead of the risk ok some rare antispam error.

Is it more comprensible now?
Back to Top
atifghaffar View Drop Down
Senior Member
Senior Member
Avatar

Joined: 31 May 2006
Location: Switzerland
Status: Offline
Points: 104
Post Options Post Options   Thanks (0) Thanks(0)   Quote atifghaffar Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 10:24am
Simone,

We also had some clients who wanted an unfiltered MX.
We set up a couple of servers for them without SF or any filtering.

Now they can choose, they can use the MX for the filtered or unfiltered.

best regards

Atif
Back to Top
LogSat View Drop Down
Admin Group
Admin Group
Avatar

Joined: 25 January 2005
Location: United States
Status: Offline
Points: 4068
Post Options Post Options   Thanks (0) Thanks(0)   Quote LogSat Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 10:27am
When we first started to implement greylisting, we debated internally if to have SpamFilter output the 400 rejection error immediately upon connection, or wait for the MAIL FROM / RCPT TO commands so we could catch more information and be more flexible with the filtering options.

We opted for option #1 (immediate rejection) as we were seing some spammers retrying continuosly even after the 400 error, but using different MAIL FROM/RCPT TO addresses. Eventually, they retried so often that the 5 minutes interval for the greylisting elapsed, and they were then allowed to connect permanently. Not good.
We instead saw that, if they received the 400 right away, without giving them a chance to specify the from/to addresses, this caused them to "give up" much sooner, and they wold not retry again.

So we decided to loose the flexibility to improve the rejection reliability. Since as of now, after about a month, and over half a billion emails processed by all the SpamFilters out there, we still did not receive a complaint about it stopping good emails... we're very tempted not to make any changes Smile
i
Roberto Franceschetti

LogSat Software

Spam Filter ISP
Back to Top
Simone View Drop Down
Groupie
Groupie


Joined: 06 July 2005
Status: Offline
Points: 42
Post Options Post Options   Thanks (0) Thanks(0)   Quote Simone Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 12:21pm
atifghaffa,

i knew that this was an option but is a little bit more than uncheck a box in the domain filter matrix :)

But i understand the roberto's explications and they are correct... unfortunatly :(
Back to Top
StevenJohns View Drop Down
Senior Member
Senior Member


Joined: 03 August 2006
Status: Offline
Points: 119
Post Options Post Options   Thanks (0) Thanks(0)   Quote StevenJohns Quote  Post ReplyReply Direct Link To This Post Posted: 11 February 2008 at 4:14am

Roberto,

I'm sure that the greylisting works very well as it is, I can see that from our small setup.

However, when a customer reports a missing email, we have no way to track it. Did it get blocked by the greylisting??? who knows??

Currently our only option would be to disable the greylisting alltogether....not what I want to do.

So, can I please ask for a half way measure....that you implement a configurable option as to when the 400 response is issued and leave that descision to us.

You could leave it to operate immediately as default, but give us the option to issue the 400 response where we would prefer it, after the rcpt copmmand.

I do understand what you are saying about the limbo timeout, but you already give us the option to change this, so having the option as to where the 400 response is issued should be is a minor change, but will give us the logging info we need to be able to report back to our customers that the missing email did not arrive or get greylisted and we have the logs to prove it.

Thanke,
 
Steve.
Back to Top
LogSat View Drop Down
Admin Group
Admin Group
Avatar

Joined: 25 January 2005
Location: United States
Status: Offline
Points: 4068
Post Options Post Options   Thanks (0) Thanks(0)   Quote LogSat Quote  Post ReplyReply Direct Link To This Post Posted: 11 February 2008 at 7:36pm
Steve,

I've added this to our wish list, but please do note that the "blacklist IP cache" filter works in the same way - rejecting connections immediately, before the MAIL FROM and RCPT TO commands are given.
Roberto Franceschetti

LogSat Software

Spam Filter ISP
Back to Top
StevenJohns View Drop Down
Senior Member
Senior Member


Joined: 03 August 2006
Status: Offline
Points: 119
Post Options Post Options   Thanks (0) Thanks(0)   Quote StevenJohns Quote  Post ReplyReply Direct Link To This Post Posted: 12 February 2008 at 3:35am
Roberto,
 
Thanks for adding it to the wish list. Hopefully it will make production soon.
 
With regard to the "Blacklist IP cache", my understanding is that this list has to be updated manually, is this not the case??
Back to Top
LogSat View Drop Down
Admin Group
Admin Group
Avatar

Joined: 25 January 2005
Location: United States
Status: Offline
Points: 4068
Post Options Post Options   Thanks (0) Thanks(0)   Quote LogSat Quote  Post ReplyReply Direct Link To This Post Posted: 12 February 2008 at 9:30am
Steve,

I'm quoting a section of our manual to explain the IP blacklist cache (it's maintained internally by SpamFilter, no user intervention is required other than enabling/disabling this filter):

Enable Cached IP Blocking - If an IP address sends more than a certain number of spam emails (3 by default) during a certain time interval (10 minutes by default), then it can be temporarily banned (blacklisted). All further connections from that IP address will be immediately rejected without allowing the sender to transmit any data. This should greatly reduce the load on the server. A banned IP address will be automatically removed from this temporary blacklist after a defined time interval (60 minutes by default). To prevent specific IPs to be added to this list, they can be added to DoNotAddIPToHoneypot SpamFilter.ini option.
Roberto Franceschetti

LogSat Software

Spam Filter ISP
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down



This page was generated in 0.078 seconds.