Greylist filter is blocking emails from Yahoo |
Post Reply |
Author | |
fastrails
Newbie Joined: 26 September 2006 Location: United States Status: Offline Points: 6 |
Post Options
Thanks(0)
Posted: 03 May 2011 at 7:57pm |
Hi, wondering if this is happening to anyone. Last couple of weeks I been having users complaining about Yahoo emails not getting through. I have narrowed it down to SFDC, if I disable it(0) Yahoo emails will get through just fine. But once enabled(5), it will allow some but will block most emails from Yahoo. I am running registered version 4.2.4.844, and prior version 4.2.4834. Let me know, thanks.
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
fastrails,
The SFDC filter blocks emails based on their contents, not based on the sender's IPs/domains. The content match is performed by analyzing, in realtime, the fingerprint (or hash) of all spam emails that are being stopped at that time. If the content fingerprint matches the fingerprint of similar content being stopped at that time, the SFDC filter blocks that email. This is again absolutely not done based on the domains/IPs. If you can zip us the original source of 2-3 such emails at support @ logsat.com we'd be glad to look over them however to ensure there are no other issues.
|
|
fastrails
Newbie Joined: 26 September 2006 Location: United States Status: Offline Points: 6 |
Post Options
Thanks(0)
|
Roberto, it's actually any emails from Yahoo. A simple plain text test message would be blocked. I am away from the office for the next couple of days, I will get them to you when I get back. BTW, is there a way to reset SFDC on the spamfilter? Thanks for the reply.
Vincent
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
If it's *all* emails from yahoo, are you certain that there isn't another filter (maybe blacklisted senders/domains/IPs that belong to Yahoo) that are blocking the emails?
I say this because the SFDC is a centralized database that all SpamFilter servers in the world use to block content. If an email you receive is blocked by the SFDC filter, then that email would be blocked by all other SpamFilters as well. If the SFDC was to block all emails from Yahoo, then all the companies using SpamFilter would not be receiving Yahoo emails as well (which is not occurring..!). As I mentioned, if you can zip us some sample, we'd be happy to see what could be happening in your case. There is no way to "reset" the SFDC filter as it is a filter we host and control. You could however increase the threshold setting for it to make it less sensitive.
|
|
fastrails
Newbie Joined: 26 September 2006 Location: United States Status: Offline Points: 6 |
Post Options
Thanks(0)
|
Roberto, let me corret myself. Not all messages from Yahoo are getting blocked. All Yahoo messages are taking a long time to receive tho, it takes about an hour before it's delivered. Gmail, after the greylisting period will deliver instantly. I did forwarded you a email with subject(RE: Failure Notice) for you to exam. Thank you.
Vin
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Vin, I was emailing you about the logs, when I saw this post bout SFDC not being the filter that blocks some of the emails, but rather being the greylist filter. This is actually why I wanted to see the activity logfile - to see which filter caused the block. If it was indeed the greylist filter, please do note that we ship SpamFilter with that filter disabled, as it can, in some cases, cause the delivery of some emails to be initially delayed. This can occur (rarely) with large providers who use dozens of non-RFC compliant SMTP servers to send their emails. Per RFC a mail server must retry to send an email if the delivery temporarily fails. Some providers violate this rule by having a different SMTP server try delivering that email instead of retrying with the same one. This does increase the delays for the delivery. Yahoo appears to be using these non-RFC compliant servers. Disabling the greylist filter will of course stop this issue with Yahoo, but you will allow more spam to get thru. Alternatively, you could try manually adding to the greylist filter configuration file the list of IPs that Yahoo uses to send mail to the file: \SpamFilter\Domains\GreyListAllowed.txt I'm attaching the list to this post. To proceed you would need to stop SpamFilter, copy/paste the entries below to the above GreyListAllowed.txt file, and restart SpamFilter. Please let me know if this does not help, so we can look into this further. 66.94.235.*~46795.0 66.94.238.*~46795.0 66.163.170.*~46795.0 66.163.178.*~46795.0 66.163.179.*~46795.0 66.196.96.*~46795.0 66.196.97.*~46795.0 66.196.100.*~46795.0 66.196.101.*~46795.0 66.196.116.*~46795.0 66.218.79.*~46795.0 66.218.94.*~46795.0 66.218.95.*~46795.0 67.195.8.*~46795.0 67.195.9.*~46795.0 67.195.13.*~46795.0 67.195.14.*~46795.0 67.195.15.*~46795.0 67.195.22.*~46795.0 67.195.23.*~46795.0 68.142.198.*~46795.0 68.142.199.*~46795.0 68.142.200.*~46795.0 68.142.201.*~46795.0 68.142.206.*~46795.0 68.142.207.*~46795.0 68.142.224.*~46795.0 68.142.225.*~46795.0 68.142.228.*~46795.0 68.142.229.*~46795.0 68.142.236.*~46795.0 68.142.237.*~46795.0 68.180.158.*~46795.0 68.180.196.*~46795.0 68.180.197.*~46795.0 68.180.198.*~46795.0 68.180.199.*~46795.0 69.147.64.*~46795.0 69.147.65.*~46795.0 69.147.69.*~46795.0 69.147.74.*~46795.0 69.147.75.*~46795.0 69.147.85.*~46795.0 69.147.92.*~46795.0 69.147.94.*~46795.0 69.147.95.*~46795.0 69.147.96.*~46795.0 69.147.97.*~46795.0 69.147.102.*~46795.0 69.147.103.*~46795.0 74.6.114.*~46795.0 74.6.228.*~46795.0 76.13.9.*~46795.0 76.13.10.*~46795.0 76.13.11.*~46795.0 76.13.12.*~46795.0 76.13.13.*~46795.0 77.238.177.*~46795.0 77.238.184.*~46795.0 77.238.189.*~46795.0 87.248.103.*~46795.0 87.248.110.*~46795.0 87.248.114.*~46795.0 87.248.115.*~46795.0 98.136.44.*~46795.0 98.136.45.*~46795.0 98.136.130.*~46795.0 98.136.164.*~46795.0 98.136.165.*~46795.0 98.136.167.*~46795.0 98.136.182.*~46795.0 98.136.183.*~46795.0 98.136.185.*~46795.0 98.137.26.*~46795.0 98.137.27.*~46795.0 98.138.82.*~46795.0 98.138.83.*~46795.0 98.138.84.*~46795.0 98.138.85.*~46795.0 98.138.87.*~46795.0 98.138.88.*~46795.0 98.138.90.*~46795.0 98.138.91.*~46795.0 98.139.52.*~46795.0 98.139.53.*~46795.0 98.139.90.*~46795.0 98.139.91.*~46795.0 111.67.240.*~46795.0 115.178.12.*~46795.0 116.214.12.*~46795.0 119.160.244.*~46795.0 119.161.5.*~46795.0 119.161.25.*~46795.0 121.101.150.*~46795.0 121.101.151.*~46795.0 124.108.96.*~46795.0 124.108.106.*~46795.0 124.108.111.*~46795.0 124.108.114.*~46795.0 124.108.115.*~46795.0 124.108.123.*~46795.0 202.1.236.*~46795.0 202.1.238.*~46795.0 202.43.196.*~46795.0 202.43.216.*~46795.0 202.43.217.*~46795.0 202.43.219.*~46795.0 202.86.4.*~46795.0 202.86.5.*~46795.0 202.165.102.*~46795.0 202.165.103.*~46795.0 202.165.105.*~46795.0 203.84.221.*~46795.0 203.104.16.*~46795.0 203.104.17.*~46795.0 203.104.18.*~46795.0 203.104.19.*~46795.0 203.188.200.*~46795.0 203.188.201.*~46795.0 203.188.202.*~46795.0 203.209.230.*~46795.0 203.209.250.*~46795.0 206.190.36.*~46795.0 206.190.37.*~46795.0 206.190.38.*~46795.0 206.190.39.*~46795.0 206.190.48.*~46795.0 206.190.49.*~46795.0 206.190.56.*~46795.0 206.190.58.*~46795.0 207.126.225.*~46795.0 209.191.68.*~46795.0 209.191.69.*~46795.0 209.191.72.*~46795.0 209.191.84.*~46795.0 209.191.85.*~46795.0 209.191.86.*~46795.0 209.191.87.*~46795.0 209.191.88.*~46795.0 209.191.90.*~46795.0 209.191.91.*~46795.0 209.191.106.*~46795.0 209.191.107.*~46795.0 209.191.124.*~46795.0 209.191.125.*~46795.0 212.82.104.*~46795.0 212.82.110.*~46795.0 212.82.111.*~46795.0 216.39.52.*~46795.0 216.39.53.*~46795.0 216.155.192.*~46795.0 216.252.110.*~46795.0 216.252.111.*~46795.0 216.252.120.*~46795.0 216.252.121.*~46795.0 217.12.10.*~46795.0 217.12.12.*~46795.0 217.12.13.*~46795.0 217.146.176.*~46795.0 217.146.177.*~46795.0 217.146.182.*~46795.0 217.146.183.*~46795.0 217.146.188.*~46795.0 217.146.189.*~46795.0 |
|
Jim Ranson
Newbie Joined: 16 May 2011 Status: Offline Points: 2 |
Post Options
Thanks(0)
|
I am having a similar problem the larger ISPs and have started a new topic about greylistin (which I think could be the problem)
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Please see new forum announcement at:
for a new whitelist that is available.
|
|
Wayne
Groupie Joined: 29 August 2006 Location: Switzerland Status: Offline Points: 60 |
Post Options
Thanks(0)
|
Hi Roberto Yesterday I did a test and sent a email over Yahoo. Today I got this "unable to deliver" report back from them. This also after we implemented all the whitelisted Yahoo IP's you suggested. How do you create this Yahoo IP list? Is there a way to find out which IP Yahoo used to deliver this email? Is this "mailer-deamon" comming always from the same mailserver from which they tried to deliver the Email? So in this header it was the 77.238.189.231 and the 212.82.108.238 or the 192.168.2.100 server? Thx Wayne-------------------------------------------------------- An: myYahooAdr@ymail.com Gesendet: 0:45 Dienstag, 18.Oktober 2011 Betreff: Failure Notice Sorry, we were unable to deliver your message to the following address. <myCompanyAdr@mydomain.ch>: Message expired for domain mydomain.ch --- Below this line is a copy of the message. Received: from [77.238.189.231] by nm21.bullet.mail.ird.yahoo.com with NNFMP; 16 Oct 2011 22:45:02 -0000 Received: from [212.82.108.238] by tm12.bullet.mail.ird.yahoo.com with NNFMP; 16 Oct 2011 22:45:02 -0000 Received: from [127.0.0.1] by omp1003.mail.ird.yahoo.com with NNFMP; 16 Oct 2011 22:45:02 -0000 X-Yahoo-Newman-Id: 750173.3769.bm@omp1003.mail.ird.yahoo.com Received: (qmail 5364 invoked from network); 16 Oct 2011 22:45:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s1024; t=1318805102; bh=MItZ2JRTSpzQQhgoqf0Y4OROfVUofqA7FKqQsAbwLtQ=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Subject:From:Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version; b=SMak9NiKxm22Gntxun+m1z0w3eX/eeHbz79XL1mVQQDaQSSRldrdXn0ImJjrZrmEJXEbNAZtRLa8rHNP4ChHCVe5QYM/uTyIKJ+KLevZqOGU3YF4DV+2+MLsowPQ3rLjKUk0ZGz6i+PaLSHRh8G9ZFJfpMtxFbeL/6VvK4NMfP8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WWQ8t1oVM1lTvvGr5Bo6pdycj39n.ECEd1M4i_IBg09fwvo gruSPG1vyc730gvtb_ddSugeGnncKPXeApq8zns.xVy5LKBUZ3gBjwJF4FlJ tivoyQ.rE0W3fTnV6b6pwCxmAjtpIIr73L7emsgM8kRZ4LnjprnNewv9zMVz NZ_rWor5Yl54M76PwWDF6yUPdUY48H29pCoVfKpLNjUM7EQ7BK1kMKBRLh3r e2sbSbHgygCnW9T4pDPW8eY3IvwsupIP4xWzOrUr.kvB49wNIcgCuyeO87S7 TeUrK85qsjliCIb.5CkBb42S0W2dtmGQdysgG6ELJ9FGC6U0KVJ51heS2sh_ F6h_DxwxyGArOl93YqXbLZyH.mZFIhg-- X-Yahoo-SMTP: 34zSj3CswBC2PerM55x7s63vQlq8A59ctQLvCxgOL.Zm Received: from [192.168.2.100] (myYahooAdr@178.82.191.237 with xymcookie) by smtp101-mob.biz.mail.ird.yahoo.com with SMTP; 16 Oct 2011 22:45:02 +0000 GMT Subject: Belkin Aircast From: Wayne <myYahooAdr@ymail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1--951999251 X-Mailer: iPhone Mail (8G4) Message-Id: <179E4653-1A91-4252-B624-15637B6AAAF6@ymail.com> Date: Mon, 17 Oct 2011 00:44:59 +0200 To: Wayne <myCompanyAdr@mydomain.ch> Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 8G4) --Apple-Mail-1--951999251 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Belkin Aircast --Apple-Mail-1--951999251 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 <html><body bgcolor="#FFFFFF"><span class="Apple-style-span" style="font-family: verdana, geneva, lucida, 'lucida grande', arial, helvetica, sans-serif; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); font-size: 22px; ">Belkin Aircast</span><div></div></body></html> --Apple-Mail-1--951999251-- Edited by Wayne - 18 October 2011 at 3:23am |
|
SF4.5.0.1-beta
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
From the the bounce email I can't tell with absolute certainty which IP address made to the connection to SpamFilter. However, based on the email headers, usually the first "Received:" in the list will report the server that will deliver the email. In this case, it should be nm21.bullet.mail.ird.yahoo.com. That hostname resolves to 212.82.108.136. This IP should already be listed in the GreyListAllowed.txt file that we are updating nightly. This is the subnet that contains it (taken fro that file): 212.82.108.*~47795.0 The updating instructions are on the posting I mentioned, which I'm including below. Did you try going thru SpamFilter's activity logfile for the 16th to see if the above IP made a connection at around 22:45 GMT?
|
|
Wayne
Groupie Joined: 29 August 2006 Location: Switzerland Status: Offline Points: 60 |
Post Options
Thanks(0)
|
Roberto
Yes I checked the IP and the log already, there is not one connection from this IP. I'm also in the Yahoo Postmaster group where they publish periodically the current outgoing mail server address list and any planned changes in the list for whitelisting, but yeah, as in the current example, often it's not actual enough. Hmmm, just another idea to improve our beloved Spamfilter application. Don't be offended please ;) If some big providers use a pool of mail servers with a shared mail queue, can't you teach then SF to check the PTR and trim this resolved name instead to use just the IP of the SMTP? As example with the Yahoo sender site like: nm21.bullet.mail.ird.yahoo.com nm18.bullet.mail.ird.yahoo.com out5.bullet.mail.ird.yahoo.com out35.bullet.mail.ird.yahoo.com Using the original grey-list key set, the first time the sending site connects, SF will record: 212.82.108.136, fromaddress@yahoo.com, myaddress@mydomain.ch Second try they use another server from their pool: 212.82.195.250, fromaddress@yahoo.com, myaddress@mydomain.ch And so on, so that's why they never came through, agree so far? If you would be able to check the PTR and trim the first word and whitelisting this trimmed PTR information, in this example: bullet.mail.ird.yahoo.com, fromaddress@yahoo.com, myaddress@mydomain.ch Wouldn't we have eliminated then all this problems? Edited by Wayne - 19 October 2011 at 6:08am |
|
SF4.5.0.1-beta
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Unfortunately not. A spammer could take his IP, and configure the PTR record for that IP to read "bullet.mail.ird.yahoo.com" (they can assign any name they want to the PTR...) when sending an email pretending to be Yahoo. That would very easily then bypass the greylist filter.
What's odd is that you did not see that IP (212.82.108.136) in the log, as from the bounce message it does appear that the delivery failed for that host. Just to confirm, did you check SpamFilter's activity logfile on the 17th (not the 16th), if I read the headers correctly and your server is located in the same timezone as the sender of the email (GMT +2)?
|
|
Wayne
Groupie Joined: 29 August 2006 Location: Switzerland Status: Offline Points: 60 |
Post Options
Thanks(0)
|
Roberto
I checked the 15th/16th and 17th But I sent you the logs now as well, looks like you don't trust me Oh and btw, I blamed Yahoo now many times coz I thought they are really violating the RFC 2821 and how you also wrote in your thread here. The greylist filter is a great tool that can be used to fight spam, as long as SMTP server follow the RFC guidelines. Per RFC, if an SMTP server is unable to deliver an email because the receiving SMTP server rejects the connection attempt with a 4xx error code (which indicates a temporary unavailability), they are supposed to retry the delivery after a few minutes. I spent yesterday a lot of time to read through all the SMTP relevant RFC documents to find where such providers are violating the RFC, but honestly, nowhere I could find something where is written, that it has to be the same SMTP server who retries to send the mail again after a 4xx. Anyway, I consider the greylisting is an abuse of SMTP standards. The server isn't really busy at all so sending a 4xx status code isn't the way the protocol was really designed. But yeah, that's a matter of opinion Thx for your help Edited by Wayne - 20 October 2011 at 8:20am |
|
SF4.5.0.1-beta
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Hi Wayne, I received the logs - could you also email me the original headers of that email above in the post, as I think you modified the to/from email addresses in there? For the RFC, it's RFC2821. Here are the relevant sections, where they define "client" and "servers", which are the two specific SMTP processes (servers) involved in the email, the "should" for retries, and the last one stating that 421 error codes must be treated like 451 error codes, Section 2.3 provides definitions of terms specific to this document. Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively. ========================================= 4.5.4.1 Sending Strategy The general model for an SMTP client is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information. 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. Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable. ============================== 3.9 Terminating Sessions and Connections An SMTP connection is terminated when the client sends a QUIT command. The server responds with a positive reply code, after which it closes the connection. An SMTP server MUST NOT intentionally close the connection except: - After receiving a QUIT command and responding with a 221 reply. - After detecting the need to shut down the SMTP service and returning a 421 response code. This response code can be issued after the server receives any command or, if necessary, asynchronously from command receipt (on the assumption that the client will receive it after the next command is issued). In particular, a server that closes connections in response to commands that are not understood is in violation of this specification. Servers are expected to be tolerant of unknown commands, issuing a 500 reply and awaiting further instructions from the client. Klensin Standards Track [Page 27] RFC 2821 Simple Mail Transfer Protocol April 2001 An SMTP server which is forcibly shut down via external means SHOULD attempt to send a line containing a 421 response code to the SMTP client before exiting. The SMTP client will normally read the 421 response code after sending its next command. SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly. ==================================== 4yz Transient Negative Completion reply The command was not accepted, and the requested action did not occur. However, the error condition is temporary and the action may be requested again. The sender should return to the beginning of the command sequence (if any). It is difficult to assign a meaning to "transient" when two different sites (receiver- and Klensin Standards Track [Page 42] RFC 2821 Simple Mail Transfer Protocol April 2001 sender-SMTP agents) must agree on the interpretation. Each reply in this category might have a different time value, but the SMTP client is encouraged to try again. A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated without any change in command form or in properties of the sender or receiver (that is, the command is repeated identically and the receiver does not put up a new implementation.) |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Hi Wayne,
Sorry for the delay - the mismatch between your nickname and real name got me real confused and I just put two and two together... :-) Ok, here's what I found. I did a search thru your logs for "212.82." and I think I finally found the right email. It originated from 212.82.109.245: 10.17.11 00:45:03:733 -- (2608) Detected TCP Connection: 212.82.109.245 and the IP actually matches the SPF host name (nm21-vm5.bullet.mail.ird.yahoo.com) mentioned in your Yahoo bounce email: From MAILER-DAEMON@yahoo.com Mon Oct 17 22:45:24 2011 X-Apparently-To: blablabla@ymail.com via 212.82.110.201; Mon, 17 Oct 2011 15:45:25 -0700 Return-Path: <> Received-SPF: none (domain of nm21-vm5.bullet.mail.ird.yahoo.com does not designate permitted sender hosts) Now here's my doubt. That subnet is present in the nightly GreyListAllowed.txt that we're publishing nightly: 212.82.109.*~47795.0 can you please check to see if that entry is in your file? |
|
Wayne
Groupie Joined: 29 August 2006 Location: Switzerland Status: Offline Points: 60 |
Post Options
Thanks(0)
|
Roberto
You are right, this entry for this subnet was not included, but the exact IP is included: 212.82.109.245~40834.0315338194 So I have to check danego's batch script if it's still working, but strange that the IP was included but the mail never delivered. So I guess it must have been another SMTP. |
|
SF4.5.0.1-beta
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Unfortunately I think the IP was the right one. Your logs show:
10.17.11 00:45:03:733 -- (2608) Detected TCP Connection: 212.82.109.245 10.17.11 00:45:03:749 -- (2608) Connection from: 212.82.109.245 - Originating country : Ireland 10.17.11 00:45:03:749 -- (2608) GreyList limbo - Added 212.82.109.245 10.17.11 00:45:03:749 -- (2608) IP is in not in GreyList Allowed. Disconnecting: 212.82.109.245 and if you had the entry "212.82.109.245~40834.0315338194" in your greylist file, then that connection should have been allowed thru. If you are positive that entry was present on the 17th, it looks like SpamFilter is having an issue with the greylist file. Please remember that the IP may have been added to your greylist file *after* 00:45 on the 17th if that IP connected again within 12 hours. This did not occur on the 17th (the IP connected again after 13 hours so didn't make the cut), but it could have happened on another day. You can find out by looking in the logs for the entry: IP Greylist - Added 212.82.109.245 to list If you don't find it, meaning that the IP was likely present before the 17th, could you please zip and email me your SpamFilter.ini and your GreyListAllowed.txt files so I can have a look? |
|
ITI Computers
Newbie Joined: 12 June 2008 Status: Offline Points: 12 |
Post Options
Thanks(0)
|
Roberto,
I think there is an issue with the Greylist. I added all the IPs from that list last night, stopped and restarted SF. This morning I see a bunch of IPs that are not passing thru that are listed in the GreyListAllowed.txt file
For example this IP is in the GreyListAllowed.txt
216.27.93.*~47795.0
And this was in my SF log this morning...
10/26/11 11:41:44:894 -- (6632) Detected TCP Connection: 216.27.93.122
10/26/11 11:41:44:894 -- (6632) Connection from: 216.27.93.122 - Originating country : United States 10/26/11 11:41:44:894 -- (6632) GreyList limbo - Added 216.27.93.122 10/26/11 11:41:44:894 -- (6632) IP is in not in GreyList Allowed. Disconnecting: 216.27.93.122 10/26/11 11:41:44:910 -- (6632) No Data Received 10/26/11 11:41:44:910 -- (6632) Disconnect |
|
ITI Computers
Web Design and Hosting |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Based on what Wayne had originally reported above, yes, it's very possible. Just as I asked Wayne, could you please zip and email us (support at logsat dot com) your SpamFilter.ini and your GreyListAllowed.txt files so we can have a look?
|
|
Wayne
Groupie Joined: 29 August 2006 Location: Switzerland Status: Offline Points: 60 |
Post Options
Thanks(0)
|
Roberto
Checked now the logs from the 16th to the 26th and I can't find a entry like "IP Greylist - Added 212.82.109.245 to list". So it must been earlier, but I don't keep this logs that long so I can't really check it. But for me it sounds logical that the entry must be in the GreyListAllowed.txt before the 17th. Sent you now the ini and greylist file. |
|
SF4.5.0.1-beta
|
|
ITI Computers
Newbie Joined: 12 June 2008 Status: Offline Points: 12 |
Post Options
Thanks(0)
|
Zippped up the files and sent them this morning. Thanks
|
|
ITI Computers
Web Design and Hosting |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Uhm... We were finally able to duplicate this thanks to both of your greylist files. This is very odd and are trying to figure out what is happening. Almost certainly this is a bug with SpamFilter. I will update this thread within the next 12/36 hours with more info.
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
The problem can occur intermittently when the GreyListAllowed.txt file contains an entry with a wildcard, followed by one or more entries that contain an IP within the above subnet. For example with this sequence:
216.27.93.*~47795.0 216.27.93.111~40822.871038831 216.27.93.112~40822.871038831 if the IP address 216.27.93.122 makes a connection, the 2 extra redundant lines with the specific IPs following the wildcarded entry may cause a mismatch. We are testing right now a beta release that automatically cleans up the GreyListAllowed.txt file upon startup to remove the redundant IPs that already fall into a wildcarded range, and should pre-release it to the public within 24/48 hours if there are no issues found with it.
|
|
Wayne
Groupie Joined: 29 August 2006 Location: Switzerland Status: Offline Points: 60 |
Post Options
Thanks(0)
|
Great news Roberto!
Thanx for your fast response! Regards Wayne |
|
SF4.5.0.1-beta
|
|
yapadu
Senior Member Joined: 12 May 2005 Status: Offline Points: 297 |
Post Options
Thanks(0)
|
Any news on this update, I started using the list provided so I will be impacted by this bug and am awaiting the fix. I don't see the update in the download area.
|
|
--------------------------------------------------------------
I am a user of SF, not an employee. Use any advice offered at your own risk. |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
FYI - the new patched build (v4.2.4.849) is now available in the registered user area.
|
|
Wayne
Groupie Joined: 29 August 2006 Location: Switzerland Status: Offline Points: 60 |
Post Options
Thanks(0)
|
Installed and testing now
Thx for the fast fix, hope our YM problems are gone now. |
|
SF4.5.0.1-beta
|
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.410 seconds.