Print Page | Close Window

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
2.7.1.511 ... my bad.


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
Originally posted by Desperado 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.



Print Page | Close Window