Re: [Declude.JunkMail] SPF uptake results in...

[Matt]

Title: Message

I've seen comments that during Christmas '02, many e-card sites would forge, but by '03 most had change their methods, and I didn't personally see any e-card issues this year.  I believe that the same thing has been happening elsewhere.  Another big issue was the send-a-link/friend stuff, but I haven't seen as much of this recently from the larger entities.  You might note that the movement to abandon forging the Mail From pre-dated SPF.  One of the possible reasons might have been the growing adoption of VERP giving such companies a realistic alternative to forging, and an awareness of this being used by servers to detect spam (seeing their own domain forged in an incoming message). On the other hand, small to medium sized entities are still forging at about the same rates.  Web site mail forms primary forge the sender as the entered E-mail address, many ecommerce apps will send receipts with the E-mail forged, and even Chrysler's official site will send inquiries sent through their system to car dealers with the sender's address forged.  I don't expect for this to change hardly at all, people that design this stuff simply have no exposure to the problems that it can create, though I do tell my developer friends to use Reply-To headers in E-mail scripts instead of forging the From.  Note that Microsoft's CDONTS has no ability to control the Mail From separate from the From, and I haven't yet seen whether or not CDO allows for this, and if it doesn't, it predisposes the developer to forge. I saw that SPF has an RFC either in development or already submitted that addresses issues with E-mail forwarding and SPF where the forwarding server should change the Mail From.  No one has implemented this to the best of my knowledge.  Forwarding is probably a bigger issue in a pure SPF sense.  I still also have many customers that send E-mail through their ISP's mail server instead of their own, much of it probably because of port 25 blocking and a lack of port 587 support/awareness. I score every domain that I scan for with a filter that detects a customer's Mail From that isn't coming from the proper mail server (which are all whitelisted), and this filter get hit a little less than 1% of total volume currently, but this is down about 60% from just a half year ago.   I suspect that spammers have wisened up a little bit and stopped forging the Mail Froms to match the server that they are targeting.  I believe that a decent portion of what is still failing that test is actually legitimate, but I only score it at 20% of my hold weight, and such messages don't typically have substantial other problems. I believe that spam filtering (and awareness) of forged addresses being received by the addressee's own server and the increased adoption of VERP is primarily responsible for the reduction in forging among the larger players, and to a smaller and later extent there has been an impact from SPF, though primarily in terms of awareness due to the buzz that these new standards created (Domain Keys and SenderID also).  I haven't noted a change in the small to medium business group however. Just so I don't get into any more trouble around here...this is just my experience/perspective, and some of it might be misstated or even completely inaccurate...and in case anyone was wondering, I do realize that I write too much :) Matt Colbeck, Andrew wrote: ... a decline in the good guys making the MAILFROM some other domain, like the target addressee itself?   I have a simple filter file called Spoof which triggers when an inbound mail has a MAILFROM in my domain instead of theirs.  Typical good-but-clueless senders included:   Fedex.com (package tracking messages) TheGlobeAndMail.com ([EMAIL PROTECTED] thought you might like this article) Sabre.com (airline reservation confirmations) Seattle-PI.com (news items as they happen)   In January however,  I've only seen spam trigger this test..   Has anybody else noted a similar new behaviour?   Andrew 8) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: Sunday, January 09, 2005 7:48 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] BlankSubject v1.0.0 external filter I coded something up for that blank subject issue.  This external test is compatible with all forms of Declude, however you should be running the most recent release or beta just to be safe. Since Declude sees intra-server E-mail as "incoming", and the goal of this filter was to target internal E-mail in order to enforce a policy, it needed a secondary match in order to verify that the message didn't only contain a blank subject, but also that it came from the address space in question. I added options for doing comparisons of the IP, reverse DNS entry and Mail From.  They work as arguments to the script like so: Match Remote IP (MIP & DIP) - This is the Match IP, and it is compared to start of the Declude IP string.  MIP=127.0.0. would match DIP=127.0.0.1, but MIP=0.0.1 would not match DIP=127.0.0.1 because it checks to see if the DIP starts with that value.  MIP is manually configured and the DIP value is provided by the %REMOTEIP% variable. Match Reverse DNS (MRD & DRD) - This is the Match Reverse DNS, and it is compared to the end of the Declude Reverse DNS string.  MRD=example.com would match DRD=computer1.example.com, but MRD=computer1 would not match DRD=computer1.example.com because that string doesn't end with the match value.  MRD is manually configured and the DRD value is provided by the %REVDNS% variable. Match Mail >From (MMF & DMF) - This is the Match Mail From, and it is compared to the end of the Declude Mail From string.  [EMAIL PROTECTED] would match [EMAIL PROTECTED], but MMF=user would not match [EMAIL PROTECTED] because that string doesn't end with the match value.  MMF is manually configured and the DMF value is provided by the %MAILFROM% variable.  ***NOTE*** since the Mail From can be forged by spammers, and some spam has blank subjects, you should only use this when it is impossible to use one of the other two match options, and if you do use it, you must make sure that you aren't causing backscatter with bounce messages. I have also added the option of doing weight skipping using SW and CW as shown in the script comments.  You can download the script from the following location:     http://www.mailpure.com/software/decludefilters/beta/BlankSubject_v1-0-0.zip There is currently a bug in all current versions of Declude that results in an external test not being run when the test definition is too long once populated with the variables.  This occurs when things get beyond about 250 characters.  It is quite possible that you will sporadically see this error with this external test and the Match Reverse DNS and Match Mail From options.  In order to work around this bug, you could place the script in the root of a drive such as C:\BlankSubject.vbs, and that should save enough space in the test definition for this not to matter. This was a rather easy script to construct once you have experience doing this stuff.  I threw this together not just to be nice, but also to inspire others to come up with external tests of their own that enhance functionality and encourage them to share.  I have run many external tests as VBScript using the CScript environment and have found that even though this is an interpreted language, it will hardly show up on your CPU utilization and the delay is virtually unnoticeable. Matt -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ ===================================================== -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================