Print Page | Close Window

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: 22 December 2024 at 9:37am


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 Wink But I sent you the logs now as well, looks like you don't trust me LOL

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 Wink

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:
212.82.109.*~47795.0
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 Wink

Thx for the fast fix, hope our YM problems are gone now.


-------------
SF4.5.0.1-beta



Print Page | Close Window