Open Relay - Masses of Spam being sent

I found what may be a major problem with this code. I had to comment it out from our servers.

Has anyone ever checked to see if, for example, mail form hotmail.com always comes from hotmail.com servers?

Or if mail from verizon.net always comes from verizon.net servers?

And so forth?

I don't think I can risk this code unless it's been checked.

Anyone?

Jeff
 
I'm surprised some invents rules just by copying another one and think changing name will be ok, but forget verifying dns.

It's easy to check smtp servers with http://www.dnsstuff.com/
and verify by sending mail from an account.

link rectified thx
 
Last edited:
Thanks, Supe. I have no idea how I managed to misread that.

However even looking at www.dnsstuff.com, I don't see any way to get the list of outgoing email servers. I suppose I can do an spf lookup on all the domains. I'll try that.

Jeff
 
I would like to test these new rules out as well and also go back to using the verify_sender option. We had alot less spam passing around back when we did and not nearly as many complaints regarding verify_sender as we now do about the ungodly amount of spam.

So could someone please post the latest version of these new rules please? Throughout the thread there have been many revisions and also multiple opinions... any consensus?

Big Wil
 
jlasman said:
Thanks, Supe. I have no idea how I managed to misread that.

However even looking at www.dnsstuff.com, I don't see any way to get the list of outgoing email servers. I suppose I can do an spf lookup on all the domains. I'll try that.

Jeff

tired jeff ;) ? first entry DNS Report
but please wait mail are tested, the whole page doesn't appears instantanly since it take time to test some entries

otherwise http://www.dnsreport.com/ same target
 
BigWil said:
I would like to test these new rules out as well and also go back to using the verify_sender option. We had alot less spam passing around back when we did and not nearly as many complaints regarding verify_sender as we now do about the ungodly amount of spam.

So could someone please post the latest version of these new rules please? Throughout the thread there have been many revisions and also multiple opinions... any consensus?

Big Wil

I tried this general sender verify but too much ressources and bad results howewer we can use callout.
I use it only in few specific rules (aol,msn,yahoo...)
 
Good idea. I would like to go with the mass majority which seems to be aol.com, yahoo.com, gmail.com, msn.net, and hotmail.com. So how do I define it on a per domain basis?

Big Wil
 
Sorry i wrote a bad idea !

You don't need to verify for aol msn yahoo, because they don't allow bad senders mail !
So if i reject with sender_helo_name and sender_host_name there are only valid mail rest.
 
Are you kidding. 80% of the yahoo and aol email addresses floating around in spam are spoofed. Of course we need to verify them.

I think it should check against the sender_helo_name and sender_host_name and then if that passes, double check the sender_verify just to be sure. But I would only do this in the case of the mass free email providers such as those I listed earlier.

Big Wil
 
Last edited:
I have no spam (ZERO) from these domains (msn yahoo aol) !!!
i just have the rules i posted on a thread, so no spoof possible.

Actually i reject 70% from mail at smtp time and have a few% spam 1% to 3% including special hardening who are not spam. The rest is ham. My mail volume is 2000/day
 
xemaps said:
first entry DNS Report
but please wait mail are tested, the whole page doesn't appears instantanly since it take time to test some entries
Not really. That only lists mx records. Large mail domains don't do incoming and outgoin on the same servers. You cannot trust that mx records point to outgoing servers. Ever. Not even on some of the domains we host.

Jeff
 
xemaps said:
I tried this general sender verify but too much ressources and bad results howewer we can use callout.
Actually a bad idea. Why? Because most spam today originates on zombie servers. And they find email addresses in the local address book and use it. So those addresses at AOL, etc., are often quite good.

Jeff
 
xemaps said:
I have no spam (ZERO) from these domains (msn yahoo aol) !!!
i just have the rules i posted on a thread, so no spoof possible.
But how many false positives are you getting? We started losing incoming mail when we implemented the rules. That's why I wrote what I did.

Jeff
 
Jeff,

So what was your end result? Are you not using these new rules at all?

Regardless they didn't do any good for us because we have a gateway machine on the outside also scanning for spam and viruses. So the host lookups were comparing against our gateway hostname and not the original HELO machine. I would still love a way of verifying the aol.com and yahoo.com addresses though. But I guess I am out of luck.

Cheers,

Big Wil
 
jlasman said:
But how many false positives are you getting? We started losing incoming mail when we implemented the rules. That's why I wrote what I did.

Jeff

sorry, i didn't see false positive for msn aol yahoo, never happens in my logs !
I make the luxe to reject spoofed mail.

Possible i have more chance than you ;)
 
jlasman said:
Actually a bad idea. Why? Because most spam today originates on zombie servers. And they find email addresses in the local address book and use it. So those addresses at AOL, etc., are often quite good.

Jeff

It's easy to reject most zombies servers by rfc checks and some tricks !
 
jlasman said:
Not really. That only lists mx records. Large mail domains don't do incoming and outgoin on the same servers. You cannot trust that mx records point to outgoing servers. Ever. Not even on some of the domains we host.

Jeff

Allowed server have to be listed in DNS, especialy carefully for these big domains which make themself a good mail prevention. They are ok whith their dns settings. Notice that you speak from mx, this is not the only entry in dns ! Alias and Cname exist, and spf add mail sender information.
 
I also lost incoming mail when testing these rules but for a different reason, it simply said the regex format was bad syntax.

failed to expand ACL string "${if match {$sender_host_name}{\N)(gmail|google).com$\N}{no}{yes}}": regular expression error in ")(gmail|google).com$": unmatched parentheses at offset 0
 
Back
Top