Greylist filter is blocking emails from Yahoo
Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=6942
Printed Date: 21 December 2024 at 10:56pm
Topic: Greylist filter is blocking emails from Yahoo
Posted By: fastrails
Subject: Greylist filter is blocking emails from Yahoo
Date 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.
|
Replies:
Posted By: LogSat
Date Posted: 04 May 2011 at 12:54am
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.
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: fastrails
Date Posted: 04 May 2011 at 11:54am
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
|
Posted By: LogSat
Date Posted: 04 May 2011 at 8:04pm
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.
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: fastrails
Date Posted: 09 May 2011 at 5:11pm
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
|
Posted By: LogSat
Date Posted: 09 May 2011 at 8:30pm
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
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: Jim Ranson
Date Posted: 16 May 2011 at 6:15am
I am having a similar problem the larger ISPs and have started a new topic about greylistin (which I think could be the problem)
|
Posted By: LogSat
Date Posted: 10 October 2011 at 8:48pm
Please see new forum announcement at: http://www.logsat.com/SpamFilter/Forums/forum_posts.asp?TID=6985 - http://www.logsat.com/SpamFilter/Forums/forum_posts.asp?TID=6985 for a new whitelist that is available.
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: Wayne
Date Posted: 18 October 2011 at 3:21am
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
--------------------------------------------------------
Von: "MAILER-DAEMON@yahoo.com" <MAILER-DAEMON@yahoo.com> 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 mailto:m.schlegel@itwgema.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: mailto:750173.3769.bm@omp1003.mail.ird.yahoo.com - 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: < mailto:179E4653-1A91-4252-B624-15637B6AAAF6@ymail.com - 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--
------------- SF4.5.0.1-beta
|
Posted By: LogSat
Date Posted: 18 October 2011 at 9:03pm
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?
The latest file is available at: http://www.logsat.com/SpamFilter/pub/GreyListAllowed.txt - http://www.logsat.com/SpamFilter/pub/GreyListAllowed.txt
to install, you will need to stop SpamFilter, add (not replace) the entries from the above file to your existing \SpamFilter\Domains\GreyListAllowed.txt file, and then restart SpamFilter. Do not worry about adding duplicates - SpamFilter will automatically parse that file upon startup, and remove any duplicates for you. |
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: Wayne
Date Posted: 19 October 2011 at 6:02am
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?
------------- SF4.5.0.1-beta
|
Posted By: LogSat
Date Posted: 19 October 2011 at 10:17pm
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)?
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: Wayne
Date Posted: 20 October 2011 at 7:55am
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 http://www.logsat.com/SpamFilter/Forums/forum_posts.asp?TID=6985 - 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
------------- SF4.5.0.1-beta
|
Posted By: LogSat
Date Posted: 20 October 2011 at 12:06pm
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.)
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: LogSat
Date Posted: 24 October 2011 at 7:26pm
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 mailto:MAILER-DAEMON@yahoo.com - MAILER-DAEMON@yahoo.com Mon Oct 17 22:45:24 2011 X-Apparently-To: mailto:m.schlegel@ymail.com - 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: can you please check to see if that entry is in your file?
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: Wayne
Date Posted: 25 October 2011 at 7:04am
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
|
Posted By: LogSat
Date Posted: 25 October 2011 at 6:18pm
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?
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: ITI Computers
Date Posted: 26 October 2011 at 12:04pm
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
|
Posted By: LogSat
Date Posted: 26 October 2011 at 10:26pm
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?
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: Wayne
Date Posted: 27 October 2011 at 3:18am
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
|
Posted By: ITI Computers
Date Posted: 27 October 2011 at 9:33am
Zippped up the files and sent them this morning. Thanks
------------- ITI Computers
Web Design and Hosting
|
Posted By: LogSat
Date Posted: 28 October 2011 at 1:23pm
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.
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: LogSat
Date Posted: 28 October 2011 at 11:01pm
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.
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: Wayne
Date Posted: 31 October 2011 at 10:03am
Great news Roberto!
Thanx for your fast response!
Regards Wayne
------------- SF4.5.0.1-beta
|
Posted By: yapadu
Date Posted: 02 November 2011 at 10:48am
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.
|
Posted By: LogSat
Date Posted: 02 November 2011 at 9:21pm
FYI - the new patched build (v4.2.4.849) is now available in the registered user area.
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: Wayne
Date Posted: 03 November 2011 at 9:33am
Installed and testing now
Thx for the fast fix, hope our YM problems are gone now.
------------- SF4.5.0.1-beta
|
|