Check valid MX record on receive
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=4597
Printed Date: 27 December 2024 at 5:21pm
Topic: Check valid MX record on receive
Posted By: BigDog
Subject: Check valid MX record on receive
Date Posted: 18 November 2004 at 4:12pm
Ok, this did seem good and I am stopping a lot of spam but I am getting a lot of messages rejected from server like mil.gov and fema.gov; also just about every list server that I have user on are also getting mail bounced due to checking for valid MX record. I am being force to turn this option off.
Not all valid out going email servers will have valid MX records, while this check does knock out some spam, is it worth losing one valid email message for every 500 messages that are spam?
|
Replies:
Posted By: LogSat
Date Posted: 18 November 2004 at 6:59pm
Wes,While technically per RFC2821 domains are not *required* to have an MX record, the RFC was written back in the days where spam was a non-issue. Nowdays things are different. Most administrators should be aware that a properly configured DNS should include one or more MX records for their email system, just like properly configured and legitimate server should have a reverse DNS entry.It would appear surprising that fema.gov does not have an MX record. However that not their only problem. If you check their DNS, you will find that they have an A record for fema.gov, 166.112.200.200. The RFC states that if the MX records is not present, mails servers should use that instead. As of right now, there is no mail server listening on that IP address, it is not a valid mail server (or it's having technical problems at the moment). To summarize, at this moment any email address in the form user@fema.gov is an invalid address, since the domain does not have a mail server. Please note that this may change if they are indeed having technical issues.The other domain you mention, mil.gov, does not appear to have a DNS entry at all, so it too will not be able to receive email right now.Roberto F.
LogSat Software
|
Posted By: keizersozay
Date Posted: 19 November 2004 at 11:21am
does spamfilter check for an A record if no MX record is found? If not, this would be helpful.
Thanks.
|
Posted By: Desperado
Date Posted: 19 November 2004 at 1:18pm
No, it does not and I agree with LogSat that it should not as the rfc does not state that a mail server *must* send to a A record if MX is not present ... only that it *should*. In my opinion, no MX is an omission from DNS and if you really have a mail server then you should insist that the DNS administrator puts an MX record in. A good argument for this is that most web sites can be hit with either http://www.domain.com" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - http://www.domain.com" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - http://www.domain.com or just simply domain.com ... using a "blank" A record. As a result of this, we always put in an MX record and if no mail server exists, then it is pointed to a server that simply nulls out all inbound mail. This way, none of our customers web servers are getting hit with mail attempts that should not go there.
I have recently modified my Sendmail server to *only* deliver to a valid MX record and not attempt to deliver to a simple A record.
Dan S.
|
Posted By: LogSat
Date Posted: 19 November 2004 at 5:01pm
As Dan correctly replied, no, we do not check for the A record. Thru research, we've seen that a large number of the spam that the MX record filter stops, is sent from domains that do have an A record. If we were to check for that, the filter would have let the email thru.Please note that the A record for a domain will most likely be there if the domain in the email exists, so checking for that to be present would practically just mean that we'd be checking only to see if the domain exists or not. We want to do more, and verifying the actual presence of the MX record has proven to be very effective. If valid domains without an MX record are found, we strongly urge administrators to notify the owners/admins of those domain to inform them that they should really get with the times and properly configure their DNS. There is no RFC that states that an email server should not be an open relay, however as we often mention some RFCs are dinosaurs, and need to get a face lift. Anyone who will say "the RFC says I don't need to close my mail server relay" will quickly appear on internet blacklists, and his mail server exploited. The MX record presence issue is very similar. It does *not* have to be there, but most administrators know that they really should have one to avoid problems.Roberto F.
LogSat Software
|
Posted By: Guests
Date Posted: 22 November 2004 at 6:21pm
I thought the purpose of this was to block ONLY spam. New features that are designed to block valid email, seem like a flaw to me.
The problem here is the term subdomain (as so many other terms used on the Internet) is defined many different ways. For the purpose of DNS, though, a subdomain MUST contain at least one entry in it's own zone record or it is not a subdomain, it is merely a host record in a subdomain.
This means that if I define listserver.domain.net as a host record in domain.net DNS zone record AND even have it listed as an MX record in domain.net AND I can send and receive email to and from this legitimate list server, I still get rejected by Logsat! This is a common scenario and there are many valid and proper uses for sending and receiving email from a host in legitimate DNS zone.
So, if you use this feature you are GUARANTEED valid wanted email gets rejected in addition to invalid unwanted email.
- Matt
|
Posted By: Desperado
Date Posted: 23 November 2004 at 10:17am
However,
If the "FROM" is something like reply@listserver.domain.net then listserver.domain.net should have an MX record to cover a valid return path and therefore no problem will exist. In this case, listserver.domain.net is, as you state a host BUT it is also a sub-domain so that the zone file might look like the following real example friom my dns server:
Domain = imeanit.com
@ TXT ( "v=spf1 ip4:66.181.192.0/20 ip4:216.244.114.0/27 a ptr mx -all" ) bounce A 66.181.193.110 MX 10 mail.bounce.imeanit.com. mail.bounce A 66.181.193.110
Where the listserver "FROM" address is mailto:campID.userID@bounce.imeanit.com" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - campID.userID@bounce.imeanit.com
When SpamFilter dows and MX lookup:
Query Type: Mail Exchanger(s) Query Value: bounce.imeanit.com
Mail Exchanger 1: Pref. 10 mail.bounce.imeanit.com |
ip addr 1: 66.181.193.110 |
And it goes through just fine. We have many customers set up with list servers and they do not get blocked as Spam for the MX lookup.
Regards,
Dan S.
|
Posted By: Guests
Date Posted: 30 November 2004 at 10:50pm
Every host that sends email must have a MX record ? Great, then you don't need SPF! I think if you're going to run a cryptic operation like that you would be better served by a product that does strictly user managed whitelisting only and rejects everything else. That's really where you are going with a feature like this. I know, I know, we can just turn the misguided feature off.
My problem is that I did not believe in a thousand years that this feature could have been implemented as such requiring every host to have an MX record. I figured that verifying the the sending domain INCLUDED an MX record was an intelligent way to filter some spam. That way if the domain had no MX record we could say there is a problem with the domain and justify not accepting the email. To turn this into a cryptic feature that requires every host to have an MX record is simply going to block lots of good email. Users beware!
-Matt
|
Posted By: Desperado
Date Posted: 01 December 2004 at 10:39am
NO ... not every *host* that sends email requires an MX record ... Every *domain* that email claims to have a return path to (ie the FROM address) needs to have an MX record otherwise, how can you mail back if there is no existing exchanger? If there is no mail exchanger, the why did the user *claim* to have a return address from a domain that can't be answered to?
SPF is totaly different. SPF maks sure that the domain the mail is claiming to be from is allowed to mail from the IP it came from.
Dan S.
|
Posted By: Guests
Date Posted: 02 December 2004 at 9:11pm
The answer to your question is simple, an MX record is not required in order to receive email! MX records point to email for the domain. So, if SpamFiltered worked properly and checked the domain it would not cause the enourmous false positives that this feature causes.
No big deal, though, just another of many empty checkbox in the program representing illogical cryptic capability.
|
Posted By: LogSat
Date Posted: 05 December 2004 at 11:40am
Matt,
Up until a few years ago, administrators would not only have never imagined to have needed an MX record, but other things were also unthinkable. While no RFC states anything in merit, not complying with any of the following examples may also prevent them from sending/receiving emails:
Locking down the mail server to avoid being an open relay. Nowdays if you don't do this the admin will end up on blacklists and providers will rejecte emails from them.
Adding a reverse DNS entry to the mail server's IP. Many providers nowdays will refuse emails unless the PTR is present.
In the near future, many providers will reject emails unless domains have SPF records in the DNS.
There is nothing in the RFC that dictates administrators must implement the above. However spam has imposed new, unwritten rules. Having a properly configured mailserver will help in the overall fight against spam. One such unwritten rule that most administrators know about is that mail servers should, not MUST, have an MX record. In the past not having one was OK, just like a few years ago it was OK to have an open relay, or not having a reverse DNS record. Not today.
We are now giving administrators one more way to reject unwanted email by demanding that the senders have a properly configured MX record.
Most domains do have an MX record in place. All anti-spam software have an accuracy rate in detecting spam that is not 100%. Any filter will at some point block legitimate emails. The MX record filter is not any different. It too will block some legitimate email, just like the others. It is the administrator's choice to see if that percentage is acceptable or not.
Roberto F. LogSat Software
|
Posted By: Guests
Date Posted: 25 February 2006 at 9:14am
I recently upgraded and have noticed a lot more false positives with this feature turned on. Rather than debate the merits of the feature, I have a question: What does the reject message look like? Does the capability exist to have invalid MX rejections bounce back with more than the generic server error message? Specifically, with a user-friendly writeup of what is discussed above? That might be helpful in alerting senders of false positives what must be done on their end to mitigate their problem. Odds are they probably do not even know about the problem. It'll give them something to take to their postmaster.
|
Posted By: LogSat
Date Posted: 25 February 2006 at 10:20am
Clator,
Do you mean false positives caused by (1) the legitimate sender not having configured his MX record properly, or (2) because the sender has a valid MX record, but SpamFilter still rejects the email?
In case of #2, if you please post or email the log entries relative to the reject we'll try to see what the problem is. In case of #1, the sender's administrators will probably want to think about correcting their configuration, as with time more and more antispam software is and will continue to use this feature.
Going back to your original question about the customization, yes, SpamFilter does already send a customizable error message explaining what the problem is. By default it's:
550 Your domain %Domain% does not have a valid MX DNS record. Disconnecting...
You can customize it (and many others) in the "Customized Items" tab under the settings tab.
------------- 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: Guests
Date Posted: 25 February 2006 at 10:35am
#1 I would imagine. Not a false positive in the programmatic sense of the world so much as a user sense.
Thanks for the info on the error. I'll try to customize it so that it is hopefully more informative to the user and will prompt him to contact his sysadmin about configuring the MX record appropriately.
|
Posted By: Guests
Date Posted: 26 February 2006 at 11:53pm
My thoughts only, but EVERY email/DNS administrator should consider publishing correct RDNS, MX, SPF so as to aid in reducing or eliminating the meriad of ways (what ever you wish to call them) spammers use to exploit the Internet to send SPAM and viruses.
What I see is that spammers are better at setting up DNS than most administrators are. Please take Roberto, Dan's and the RFC's excellent advice and setup DNS as recommended and help other administrators who are less informed as to why they should do the same.
I do help other adiministrators and it really helps to keep your users happy by eliminating spam and near zero false positiives.
|
Posted By: Guests
Date Posted: 27 February 2006 at 8:57am
I trapped an email in the quarantine from my in-laws who use Cox Hi-Speed, with the invalid MX record error in the log. This is curious, as Cox is of course a major national provider. Is this evidence of a #2 error as described above?
Here are the relevant headers, modified to remove personal info:
Received: from [my in-laws username] ([70.186.195.204]) by eastrmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id < mailto:20060226204937.OAJY3108.eastrmmtao05.cox.net@my - 20060226204937.OAJY3108.eastrmmtao05.cox.net@[my in-laws username]> for <[ mailto:ellen@clator.com - mywife's username] @ mydomain >; Sun, 26 Feb 2006 15:49:37 -0500 Message-ID: < mailto:002901c63b17$5395f160$ccc3ba46@my - 002901c63b17$5395f160$ccc3ba46@[my inlaws]> From: "[My In-laws]" < mailto:my@cox.net - [my inlaws]@cox.net >
|
Posted By: LogSat
Date Posted: 27 February 2006 at 4:05pm
cox.net does indeed have a correctly configured MX record, the email should not have been rejected for that casue. We did have a bug in one of the latest pre-release builds of SpamFilter, where a socket error could cause the MX record test to fail. This was fixed in build 2.7.1.531. What verison of SpamFilter are you using?
------------- 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: Guests
Date Posted: 27 February 2006 at 10:54pm
2.7.1.515
That was the version available to me being a non-paying individual user. Woe is me I guess until the next generally available release I suppose.
Finding a lot of these false positives in the meantime. *sigh*
Thanks for your help.
|
Posted By: Guests
Date Posted: 27 February 2006 at 10:56pm
Posted By: LogSat
Date Posted: 27 February 2006 at 11:11pm
If you can post some of the SpamFilter's activity log entries for those rejected emails we can try to see if the problem is the same one fixed by the newer builds or now.
------------- 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: Guests
Date Posted: 27 February 2006 at 11:40pm
Just got another one:
02/27/06 23:29:26:292 -- (444) Resolving 66.135.197.13 - Error resolving IP address (Socket Error # 10054 Connection reset by peer.) 02/27/06 23:29:26:401 -- (444) - Invalid MX record - Socket Error # 10054 Connection reset by peer. 02/27/06 23:29:26:401 -- (444) 66.135.197.13 - Mail from: mailto:spoof@ebay.com - spoof@ebay.com To: [my address] will be rejected 02/27/06 23:29:27:245 -- (444) EMail from mailto:spoof@ebay.com - spoof@ebay.com to mailto:clator@clator.com - [my address] was received and quarantined. Size: 29 KB, 29696 bytes 02/27/06 23:29:27:276 -- (956) Time to add Msg to Bayes corpus:15 02/27/06 23:29:27:292 -- (444) Blacklist cache - Added 66.135.197.13 to limbo 02/27/06 23:29:27:292 -- (444) Disconnect
|
Posted By: Guests
Date Posted: 27 February 2006 at 11:46pm
here's another. Not sure if it's a 1 or a 2.
02/27/06 17:54:07:073 -- (1296) Connection from: 63.174.99.34 - Originating country : United States 02/27/06 17:54:07:511 -- (1296) Resolving 63.174.99.34 - Error resolving IP address (Socket Error # 10054 Connection reset by peer.) 02/27/06 17:54:07:620 -- (1296) - Invalid MX record - Socket Error # 10054 Connection reset by peer. 02/27/06 17:54:07:620 -- (1296) 63.174.99.34 - Mail from: mailto:validjcarson@tmalist.com - [valid user]@tmalist.com To: mailto:clator@clator.com - [me] will be rejected 02/27/06 17:54:07:776 -- (1296) EMail from mailto:valid@tmalist.com - [valid user]@tmalist.com to mailto:clator@clator.com - [me] mailto:clator@clator.com - was received and quarantined. Size: 6 KB, 6144 bytes 02/27/06 17:54:07:807 -- (956) Time to add Msg to Bayes corpus:0 02/27/06 17:54:07:823 -- (1296) Blacklist cache - Added 63.174.99.34 to limbo 02/27/06 17:54:07:823 -- (1296) Disconnect
|
Posted By: LogSat
Date Posted: 27 February 2006 at 11:50pm
Unfortunately that does look very much like the symptom in my original reply "where a socket error could cause the MX record test to fail". That has been solved in the latest releases, sorry...
------------- 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: Analytical
Date Posted: 28 February 2006 at 10:30am
I have been using the MX filter with great success. I had a few people get false positives but those few are now whitelisted per their personal spamfilter web interface. The MX filter is blocks about 1000 pieces of spam every two days. This is a great feature!
------------- His and yours,
Dwight
|
Posted By: Desperado
Date Posted: 28 February 2006 at 12:55pm
Here are my stats for the first half of today. Invalid MX is way down on the list but still ... 2000 messages. Also, often, during "Spam Attacks", the invalid MX test is the only thing that blocks them so it bumps up to as high a 30%
|
javascript ;" target=_blank onclick="set_sort_column0, 'reason'; return false; - Reason |
javascript ;" target=_blank onclick="set_sort_column0, 'messages'; return false; - Messages |
|
javascript ;" target=_blank onclick="set_sort_column0, 'bytes'; return false; - Bytes |
1 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'was__HexEsc__20queued'; return false; - was queued |
16,160 |
14.5 % |
|
499.84 M |
2 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'IP__HexEsc__20is__HexEsc__20in__HexEsc__20local__HexEsc__20blacklist__HexEsc__20cache'; return false; - IP is in local blacklist cache |
15,729 |
14.1 % |
|
0 b |
3 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Reverse__HexEsc__20DNS__HexEsc__20not__HexEsc__20found'; return false; - Reverse DNS not found |
15,369 |
13.8 % |
|
60.01 M |
4 |
javascript ;" target=_blank onclick="zoom0, 'reason', '__HexEsc__20Whitelisted__HexEsc__20EMail__HexEsc__20Address__HexEsc__20To'; return false; - Whitelisted EMail Address To |
14,424 |
12.9 % |
|
159.58 M |
5 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Blacklisted__HexEsc__20by__HexEsc__20sbl-xbl.spamhaus.org.__HexEsc__20'; return false; - Blacklisted by sbl-xbl.spamhaus.org. |
13,273 |
11.9 % |
|
63.98 M |
6 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'SPF__HexEsc__20test'; return false; - SPF test |
7,144 |
6.4 % |
|
16.67 M |
7 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Probe__HexEsc__20or__HexEsc__20Unknown'; return false; - Probe or Unknown |
5,718 |
5.1 % |
|
109.00 k |
8 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'EmailTO__HexEsc__20is__HexEsc__20in__HexEsc__20local__HexEsc__20blacklist__HexEsc__20file'; return false; - EmailTO is in local blacklist file |
5,382 |
4.8 % |
|
18.00 k |
9 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Blacklisted__HexEsc__20by__HexEsc__20multi.surbl.org.__HexEsc__20'; return false; - Blacklisted by multi.surbl.org. |
4,110 |
3.7 % |
|
17.27 M |
10 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Blacklisted__HexEsc__20by__HexEsc__20combined.njabl.org.__HexEsc__20'; return false; - Blacklisted by combined.njabl.org. |
2,909 |
2.6 % |
|
13.59 M |
11 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Invalid__HexEsc__20MX__HexEsc__20record'; return false; - Invalid MX record |
2,170 |
1.9 % |
|
10.62 M |
12 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'content__HexEsc__20filter'; return false; - content filter |
1,537 |
1.4 % |
|
23.34 M |
13 |
javascript ;" target=_blank onclick="zoom0, 'reason', '__HexEsc__20Whitelisted__HexEsc__20EMail__HexEsc__20Address__HexEsc__20From'; return false; - Whitelisted EMail Address From |
1,487 |
1.3 % |
|
19.08 M |
14 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Too__HexEsc__20many__HexEsc__20connections'; return false; - Too many connections |
1,457 |
1.3 % |
|
0 b |
15 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Blacklisted__HexEsc__20by__HexEsc__20bl.spamcop.net.__HexEsc__20'; return false; - Blacklisted by bl.spamcop.net. |
1,329 |
1.2 % |
|
8.35 M |
16 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'EmailFrom__HexEsc__20is__HexEsc__20in__HexEsc__20local__HexEsc__20blacklist__HexEsc__20file'; return false; - EmailFrom is in local blacklist file |
1,009 |
0.9 % |
|
2.66 M |
17 |
javascript ;" target=_blank onclick="zoom0, 'reason', '__HexEsc__20AutoWhiteList__HexEsc__20Force__HexEsc__20Delivery'; return false; - AutoWhiteList Force Delivery |
870 |
0.8 % |
|
157.63 M |
18 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'no__HexEsc__20relay__HexEsc__20allowed'; return false; - no relay allowed |
612 |
0.6 % |
|
0 b |
19 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'infected__HexEsc__20with__HexEsc__20the__HexEsc__20virus'; return false; - infected with the virus |
320 |
0.3 % |
|
20.63 M |
20 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'IP__HexEsc__20address__HexEsc__20is__HexEsc__20from__HexEsc__20a__HexEsc__20blacklisted__HexEsc__20country'; return false; - IP address is from a blacklisted country |
252 |
0.2 % |
|
1.20 M |
21 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Blacklisted__HexEsc__20by__HexEsc__20dnsbl.mags.net.__HexEsc__20'; return false; - Blacklisted by dnsbl.mags.net. |
238 |
0.2 % |
|
867.00 k |
22 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'IP__HexEsc__20is__HexEsc__20in__HexEsc__20local__HexEsc__20blacklist__HexEsc__20file'; return false; - IP is in local blacklist file |
188 |
0.2 % |
|
144.00 k |
23 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Blocked__HexEsc__20by__HexEsc__20Honeypot__HexEsc__20Autofilter'; return false; - Blocked by Honeypot Autofilter |
41 |
0.0 % |
|
105.00 k |
24 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Exceeded__HexEsc__20maximum__HexEsc__20number__HexEsc__20of__HexEsc__20RCPT__HexEsc__20TO'; return false; - Exceeded maximum number of RCPT TO |
34 |
0.0 % |
|
89.00 k |
25 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Blacklisted__HexEsc__20by__HexEsc__20relays.ordb.org.__HexEsc__20'; return false; - Blacklisted by relays.ordb.org. |
16 |
0.0 % |
|
154.00 k |
26 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Empty__HexEsc__20Mail__HexEsc__20From'; return false; - Empty Mail From |
6 |
0.0 % |
|
0 b |
27 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'Domain__HexEsc__20is__HexEsc__20in__HexEsc__20local__HexEsc__20blacklist__HexEsc__20file'; return false; - Domain is in local blacklist file |
5 |
0.0 % |
|
105.00 k |
28 |
javascript ;" target=_blank onclick="zoom0, 'reason', 'No__HexEsc__20Data__HexEsc__20Received'; return false; - No Data Received |
4 |
0.0 % |
|
0 b |
29 |
javascript ;" target=_blank onclick="zoom0, 'reason', '__HexEsc__20Whitelisted__HexEsc__20Peer__HexEsc__20IP'; return false; - Whitelisted Peer IP |
1 |
0.0 % |
|
1024 b |
|
Total |
111,794 |
100 % |
|
1.05 G |
------------- The Desperado
Dan Seligmann.
Work: http://www.mags.net
Personal: http://www.desperado.com
|
Posted By: Guests
Date Posted: 28 February 2006 at 7:57pm
I sent in a message to the sales address about obtaining a license for a home-based server like mine but haven't heard back. Was that received? My quarantine didn't show any replies either, but I don't quarantine everything. Just curious.
|
Posted By: LogSat
Date Posted: 28 February 2006 at 10:05pm
We just found it in our quarantine, the IP is blacklisted by dnsbl.sorbs.net... I'll reply to the email right now.
------------- 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: Guests
Date Posted: 03 March 2006 at 8:57am
Lovely. Undoubtedly caused by some spammer who had the IP at some point. I'll see if I can get it un-blacklisted. Thanks.
|
Posted By: Guests
Date Posted: 03 March 2006 at 9:00am
P.S. ... what was the IP that was blacklisted? I wonder if it was mine or the Comcast SMTP server.
|
Posted By: Desperado
Date Posted: 03 March 2006 at 9:37am
COMMENT ON SORBS:
We had to stop using SORBS. They adopted a policy of charging for being de-listed and as a result most folks don't bother. I had a bitter argument with them on several IP's that were blocked. I feel the list (which used to be fantastic) is now very problematic and we saw a huge upsurge in false positives.
------------- The Desperado
Dan Seligmann.
Work: http://www.mags.net
Personal: http://www.desperado.com
|
Posted By: Guests
Date Posted: 03 March 2006 at 10:35am
Just upgraded to .532 and have gotten a couple more false positives as described above. The cox.net address in particular.
|
Posted By: LogSat
Date Posted: 03 March 2006 at 4:15pm
Clator,
Can you post (or email us) the SpamFilter's logfile entries that show these false positives? We'll need to see the log to find out what is happening.
------------- 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: dcook
Date Posted: 03 March 2006 at 6:03pm
I am currently having success with the following maps setting: sbl-xbl.spamhaus.org, true combined.njabl.org, true bl.spamcop.net, true block.rhs.mailpolice.com, true dul.dnsbl.sorbs.net, true
tanks alot
------------- Dwight www.vividmix.com
|
Posted By: WebGuyz
Date Posted: 03 March 2006 at 6:24pm
Desperado wrote:
COMMENT ON SORBS:
We had to stop using SORBS. They adopted a policy of charging for being de-listed and as a result most folks don't bother. I had a bitter argument with them on several IP's that were blocked. I feel the list (which used to be fantastic) is now very problematic and we saw a huge upsurge in false positives.
|
Same here. Did you delete your Bayes Corpus and let it grow again or just leave it be after you dropped SORB? The Bayes catch rate is great now but maybe a little too sensitive, still trying to figure out.
Thinking that any major change may require a corpus dump to make bayes 'forget' about what it caught using whatever it was you stopped using.
------------- http://www.webguyz.net
|
Posted By: Guests
Date Posted: 07 March 2006 at 2:19pm
Posted these in the wrong thread. They should go here.
Per Dan's suggestion, Ive created a new corpus directory. Meanwhile some of the domains that are failing MX checks are elon.edu, aapa.org, and gci.net. Sorry I don't have the full headers at the moment. I went ahead and forced the messages through.
Some more potential false positives ...
Received: from 205.188.139.137 by clator.com (LogSat Software SMTP Server - Unlicensed Evaluation Copy) Tue, 7 Mar 2006 08:01:11 -0500 Received: from [...] by imo-d23.mx.aol.com (mail_out_v38_r7.3.) id 3.214.1439293c (3657) for <...>; Tue, 7 Mar 2006 08:01:07 -0500 (EST) From: [...]Message-ID: < mailto:...@aol.com - ...@aol.com > Date: Tue, 7 Mar 2006 08:01:07 EST Subject: Club Mom info from [...] To: [...]MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="part1_214.1439293c.313ede13_boundary" X-Mailer: 9.0 SE for Windows sub 5021 X-Spam-Flag: NO X-Server: LogSat Software SMTP Server - Unlicensed Evaluation Copy X-SF-RX-Return-Path: <...> X-SF-HELO-Domain: imo-d23.mx.aol.com Back to Top Clator Guest Group
Joined: 25 January 2005 Online Status: Online Posts: 2999 Posted: 07 March 2006 at 8:18am | IP Logged
------------------------------------------------------------ --------------------
and another ... personall details removed again to keep the bots from picking it up.
Received: from 204.127.192.82 by clator.com (LogSat Software SMTP Server - Unlicensed Evaluation Copy) Mon, 6 Mar 2006 19:34:08 -0500 Received: from mack ([node].hsd1.va.comcast.net[69.143.209.237]) by comcast.net (rwcrmhc12) with SMTP id <20060307003406m12001ichve>; Tue, 7 Mar 2006 00:34:07 +0000 Message-ID: < mailto:000a01c6417e$9c3c9aa0$6401a8c0@mack - 000a01c6417e$9c3c9aa0$6401a8c0@mack > Reply-To: "..." < mailto:...@comcast.net - ...@comcast.net > From: "..." < mailto:...@comcast.net - ...@comcast.net > To: <...> Subject: Simpsons video Date: Mon, 6 Mar 2006 19:32:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C64154.B2EC5990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Server: LogSat Software SMTP Server - Unlicensed Evaluation Copy X-SF-RX-Return-Path: < mailto:...@comcast.net - ...@comcast.net > X-SF-HELO-Domain: rwcrmhc12.comcast.net
more. several legit mails from Amazon.com getting caught. Here's an example.
Received: from 207.171.160.42 by clator.com (LogSat Software SMTP Server - Unlicensed Evaluation Copy) Tue, 7 Mar 2006 13:33:57 -0500 Received: from na-rte-app-5102.iad5.amazon.com ([10.216.250.37]) by mm-notify-out-2103.amazon.com with ESMTP; 07 Mar 2006 10:32:55 -0800 Received: by na-rte-app-5102.iad5.amazon.com id AAA-notification-29959,8591; 7 Mar 2006 10:32:37 -0800 Date: 7 Mar 2006 10:32:37 -0800 Message-ID: < mailto:...@na-rte-app-5102.iad5.amazon.com - ...@na-rte-app-5102.iad5.amazon.com > X-AMAZON-TRACK: notification To: mailto:...@clator.com - ...@clator.com From: "Amazon.com Payments" < mailto:gameowner@msn.com - gameowner@msn.com > Subject: Your Amazon Marketplace Purchase Cc: mailto:payments-mail@amazon.com - payments-mail@amazon.com Bounces-to: mailto:...@bounces.amazon.com - ...@bounces.amazon.com Content-Type: text/plain MIME-Version: 1.0 X-AMAZON-MAIL-RELAY-TYPE: notification X-Server: LogSat Software SMTP Server - Unlicensed Evaluation Copy X-SF-RX-Return-Path: < mailto:...@bounces.amazon.com - ...@bounces.amazon.com > X-SF-HELO-Domain: mm-notify-out-2103.amazon.com
a legit one from turner.com ...
Received: from 64.236.240.147 by clator.com (LogSat Software SMTP Server - Unlicensed Evaluation Copy) Tue, 7 Mar 2006 13:52:01 -0500 Received: from CNNCIMSS05.turner.com (cnncimss05.turner.com [10.188.171.204]) by smtpgw2.turner.com (8.12.10/8.12.11) with ESMTP id k27Ipw4c020541 for < mailto:...@clator.com - ...@clator.com >; Tue, 7 Mar 2006 13:51:59 -0500 (EST) Received: from ATLBH01.turner.com ([10.188.157.231]) by CNNCIMSS05.turner.com with InterScan Messaging Security Suite; Tue, 07 Mar 2006 13:51:58 -0500 Received: from ATLPF02.turner.com ([10.188.156.206]) by ATLBH01.turner.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Mar 2006 13:51:58 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64218.363A93AC" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Top Stories Date: Tue, 7 Mar 2006 13:51:58 -0500 Message-ID: < mailto:BA010952EAB04749A22AE36AB1A1037C0265C3FF@ATLPF02.turner.com - BA010952EAB04749A22AE36AB1A1037C0265C3FF@ATLPF02.turner.com > X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: General Comments Thread-Index: AcZCGDY1/nirXhlcS1SlO6wZI18H7gAAAAAK From: "News in General" < mailto:Topstories4@turner.com - Topstories4@turner.com > To: < mailto:...@clator.com - ...@clator.com > X-OriginalArrivalTime: 07 Mar 2006 18:51:58.0531 (UTC) FILETIME=[365C6130:01C64218] X-Server: LogSat Software SMTP Server - Unlicensed Evaluation Copy X-SF-RX-Return-Path: < mailto:Topstories4@turner.com - Topstories4@turner.com > X-SF-HELO-Domain: smtpgw2.turner.com
a legit one from turner.com ...
Received: from 64.236.240.147 by clator.com (LogSat Software SMTP Server - Unlicensed Evaluation Copy) Tue, 7 Mar 2006 13:52:01 -0500 Received: from CNNCIMSS05.turner.com (cnncimss05.turner.com [10.188.171.204]) by smtpgw2.turner.com (8.12.10/8.12.11) with ESMTP id k27Ipw4c020541 for < mailto:...@clator.com - ...@clator.com >; Tue, 7 Mar 2006 13:51:59 -0500 (EST) Received: from ATLBH01.turner.com ([10.188.157.231]) by CNNCIMSS05.turner.com with InterScan Messaging Security Suite; Tue, 07 Mar 2006 13:51:58 -0500 Received: from ATLPF02.turner.com ([10.188.156.206]) by ATLBH01.turner.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Mar 2006 13:51:58 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64218.363A93AC" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Top Stories Date: Tue, 7 Mar 2006 13:51:58 -0500 Message-ID: < mailto:BA010952EAB04749A22AE36AB1A1037C0265C3FF@ATLPF02.turner.com - BA010952EAB04749A22AE36AB1A1037C0265C3FF@ATLPF02.turner.com > X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: General Comments Thread-Index: AcZCGDY1/nirXhlcS1SlO6wZI18H7gAAAAAK From: "News in General" < mailto:Topstories4@turner.com - Topstories4@turner.com > To: < mailto:...@clator.com - ...@clator.com > X-OriginalArrivalTime: 07 Mar 2006 18:51:58.0531 (UTC) FILETIME=[365C6130:01C64218] X-Server: LogSat Software SMTP Server - Unlicensed Evaluation Copy X-SF-RX-Return-Path: < mailto:Topstories4@turner.com - Topstories4@turner.com > X-SF-HELO-Domain: smtpgw2.turner.com
and lastly, three of these were caught. All of the above postings were just in the past six hours and were only to me (not being an actual ISP, it's jsut me and the missus using the clator.com domain).
Hopefully these will point to some issues. In case it hasn't been said, thanks for any help you can provide.
Received: from 68.230.240.34 by clator.com (LogSat Software SMTP Server - Unlicensed Evaluation Copy) Tue, 7 Mar 2006 13:56:40 -0500 Received: from willowoffice ([70.187.202.109]) by eastrmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id < mailto:...eastrmmtao05.cox.net@willowoffice - ...eastrmmtao05.cox.net@willowoffice > for < mailto:...@clator.com - ...@clator.com >; Tue, 7 Mar 2006 13:54:21 -0500 From: "..." < mailto:...@willowtreemedia.com - ...@willowtreemedia.com > To: < mailto:...@clator.com - ...@clator.com > Subject: FW: BIOS and Photos for Fertility C.A.R.E Date: Tue, 7 Mar 2006 13:50:19 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01C641EE.12D79CE0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYQqJIy9GiFULfASdW33ufOnhb1nQxboDEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Message-Id: < mailto:....eastrmmtao05.cox.net@willowoffice - ....eastrmmtao05.cox.net@willowoffice > X-Server: LogSat Software SMTP Server - Unlicensed Evaluation Copy X-SF-RX-Return-Path: < mailto:...@willowtreemedia.com - ...@willowtreemedia.com > X-SF-HELO-Domain: eastrmmtao05.cox.net
|
Posted By: LogSat
Date Posted: 07 March 2006 at 4:06pm
Clator,
We'll need to see SpamFilter's activity logfiles showing those emails, as in the logs will be reported the reason for the failure, and we need to cross-reference with the emails themselves you just posted.
------------- 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: Guests
Date Posted: 07 March 2006 at 5:10pm
Sure thing. Is there an email address I should just send the logs to? I can send them unaltered that way. (No bots to pick up the various addresses and whatnot).
Thanks.
|
Posted By: LogSat
Date Posted: 07 March 2006 at 8:10pm
Clator,
Your logs still show the DNS disconnecting SpamFilter when queries are made:
03/07/06 08:01:11:368 -- (404) Resolving 205.188.139.137 - Error resolving IP address (Socket Error # 10054 Connection reset by peer.) 03/07/06 08:01:11:368 -- (404) - Invalid MX record - Socket Error # 10054 Connection reset by peer.
We thought we had modified the MX filter so that forceful disconnects from the DNS server that would cause MX lookups to fail would not cause the filter to fail. Apparently your case is slightly different,and our workaround does not work. We'll try to replicate the problem and ignore the error you are receiving as well.
In the meantime, you may want to check the connection to your DNS server to see if you can find out why it fails every now and then.
------------- 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: 07 March 2006 at 9:36pm
We've uploaded build 2.7.1.535 in the registered user area. The release notes are as follows:
// New to VersionNumber = '2.7.1.535'; {TODO -cFix : Sometimes Socket Errors on MX test could cause rejects (catches more cases than in build 531)} {TODO -cNew : Changed the precedence for the :tag and :tagsubject modifiers for the Unfiltered Emails} {TODO -cFix : DoNotStartWithoutAV option in SpamFilter.ini file not working correctly}
------------- 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: Guests
Date Posted: 10 March 2006 at 10:05am
Thanks again. I've discovered an internal 10. address where my server is hosted that may prove more reliable for DNS than the current IP. Hopefully this'll do it.
|
|