Received: from nycars.com [24.92.238.169] by igaia.com with ESMTP
I host both of these domains, though that is the IP of a cable modem account. What's happening here (I have confirmed this) is that the connecting computer has an actual account on igaia.com and is set up for SMTP using that domain. His from address in his E-mail program though says [EMAIL PROTECTED] (he has an alias there) and somehow the server isn't using his computer name, but instead is using the domain in his from address that is also hosted on my server. It's also possible that the server isn't doing this and Netscape 7 is. I haven't figured that part out yet.
This does in fact look to be a fairly uncommon exception, however I have several domains with users set up like this. WHITELIST AUTH would of course prevent such things from getting scored, but since I'm not running IMail 8, it seems that the only way around would be to exclude the offending domains from my list, and try to remember not to add any such domains in the future. This is a risky proposition though because some of my customers that have multiple domains are free to change their E-mail client configurations at whatever time they wish.
BTW, I have my router set up to prevent spoofing, but I'm no expert there. Would you mind sharing the essence of the rule that you are using for this? Also, a little information on some of the associated rules would also be appreciated. In particular the one that checks REVDNS for .in-addr.arpa. Obviously you are checking for something particular there.
Thanks,
Matt
Karen D. Oland wrote:
We've done this for over a year (and block true IP forging at the routers -- the test gets the ones that forge HELO as the IP). No false positives (I am often out of the office with my notebook and use SMTP AUTH to send then, no problems), lots of spam. You do NOT need any of the below, as the test grabs up only those who are forging the name or IP of the mail server receiving the mail (and if you have multiple email servers, they should have different names, IP's and versions of this test or offset catching partial domain matches by using negative weight for internal IP's). This works just find on IMAIL 7.x, Declude (all version for last year or so) and does not require WHITELIST AUTH. I'm not sure what part of these rules you see requiring the more advanced features of IMAIL 8?
The only difference in the tests below and the ones we use is that we do a full match on some (IS not CONTAINS) as analysis of our log files showed that those who pull this type of forging always do a complete matchup, not a partial forgery (that we have seen so far). I use CONTAINS on domain name, as notebooks coming from the outside never include the domain their authentication (that I have seen). In any case, the original poster is using a fairly low weight (for us) to flag these --- we hold any forged HELO/EHLO automatically and have never had a false positive due to it.
Specificaly, we use (with our domain instead of "example" and out internal IP instead of "x.x.x.x"):
# catch attempt to pretend to be us HELO 15 CONTAINS example.com HELO 30 IS x.x.x.x HELO 30 IS 127.0.0.1 HELO 30 CONTAINS $domain HELO 15 STARTSWITH [ REVDNS 15 ENDSWITH .in-addr.arpa
where 10 is a review weight (used to be 15), 30 is hold (reviewed bi-monthly, possibly, only searched if something expected is missing -- I've only ever had one legit msg held in over a year, even as we dropped this from 60 down to 30). 60 is delete (as are many banned senders and porn site/senders). As our FP rate at 10-30 is so low and I can't remember one over 20 in a long time, the hold weight will probably be dropping soon.
Karen Oland
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Matthew Bramble Sent: Tuesday, September 23, 2003 1:16 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Another very effective filter test
Bill,
One other very important note. You need to be using IMail 8, WHITELIST AUTH with Declude 1.76b and make sure that all the mail clients are configured to use SMTP AUTH, otherwise intra-server E-mail is going to get tagged. I can't use this in it's present form because I'm using IMail 7 :(
Am I missing something?
Matt
Bill Landry wrote:
This test is very effective at flagging or blocking spam from mail hostsown hostnames
that attempt to connect to your mail server and announce your
or IP addresses to it in their HELO string, especially if yourIMail/Declude
server is directly sending and receiving mail from the Internet (lessIMail/Declude).
functional, but still works if relaying via mail gateway to
there attemptThis filter looks for the bogus HELO info in the headers. In my testing, 100% of the messages delivered by these mail hosts is spam.
Think about it, why would any other legitimate mail server out
to connect to your mail server announcing your own hostname orIP address in
its HELO string? The answer is, it wouldn't. Anyway, here is the test I use to detect these.
In global.cfg: FORGEDHELO-FILTER filter M:\IMail\Declude\ForgedHelo-Filter.txt x 7 0
In ForgedHelo-Filter.txt file: ===== # In case you have mail gateways, deduct equal weight for these hosts HELO -7 ENDSWITH gw1.yourdomain.com HELO -7 ENDSWITH gw2.yourdomain.com
# Remote mail hosts connecting and announcing your IP addresses HELO 0 CONTAINS xxx.xxx.xxx. HELO 0 CONTAINS xxx.xxx.xxx.
# Remote mail hosts connection and announcing your hostnames HELO 0 ENDSWITH your-host.com HELO 0 ENDSWITH your-host.net HELO 0 ENDSWITH cust-host.com HELO 0 ENDSWITH cust-host.net =====
If you are not already running a test like this, try it out. I think you will find that it will flag lots of spam.
Bill
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
