RE: [Declude.JunkMail] SPF Issue
One thing, Serge. You don't need both TXT records. The one called mail is useless. p.s. here's yet another SPF record checking website http://www.kitterman.com/spf/validate.html Andrew. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Tuesday, September 02, 2008 9:12 PM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] SPF Issue Seems all is OK thank you al for your help Serge - Original Message - From: Andy Schmidt [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Tuesday, September 02, 2008 2:46 AM Subject: RE: [Declude.JunkMail] SPF Issue I checked your 4 DNS servers. dns2 is down, but the other 3 all returned the same, valid SPF record. (Despite what Pete said, your SPF syntax is perfectly valid and quite usual.) Based on what you posted, DNSSTUFF contacted your ns1.cefib.com for the TXT record without success. May have been a temporary problem? Do you actually have any MAIL problems related to SPF? What you are reporting here, doesn't seem to be an SPF problem, but rather a DNS problem! You can always use one of the email based record tester on http://www.openspf.org/Tools to confirm that your SPF record is recognized AND handled correctly by third party servers. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Monday, September 01, 2008 7:16 PM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] SPF Issue Here is what i get from DNSSTUFF Not sure what else to do to find out what is going on How I am searching: Searching for cefib.com SPF record at f.root-servers.net [192.5.5.241]: Got referral to D.GTLD-SERVERS.NET. (zone: com.) [took 59 ms] Searching for cefib.com SPF record at D.GTLD-SERVERS.NET. [192.31.80.30]: Got referral to ns1.cefib.com. (zone: cefib.com.) [took 31 ms] Searching for cefib.com SPF record at ns1.cefib.com. [217.64.107.100]: Reports that no SPF records exist. [took 301 ms] Response: No SPF records exist for cefib.com. [Neg TTL=3540 seconds] Details: ns1.cefib.com. (an authoritative nameserver for cefib.com.) says that there are no SPF records for cefib.com. The E-mail address in charge of the cefib.com. zone is: [EMAIL PROTECTED] There is no need to refresh the page -- to see the DNS traversal, to make sure that all DNS servers are reporting the same results, you can Click Here. Note that these results are obtained in real-time, meaning that these are not cached results. These results are what DNS resolvers all over the world will see right now (unless they have cached information). - Original Message - From: Andy Schmidt [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Monday, September 01, 2008 12:41 PM Subject: RE: [Declude.JunkMail] SPF Issue What is the issue? What error message? Was it bounced mail? What did the NDR say? I could be a recipient trying to forward mail to another server, or an end-user trying to send email from home using their local ISP... etc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Sunday, August 31, 2008 10:18 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SPF Issue Hi all I have som SPF issues It was working fine some times back I use Mixrosoft dns I have (same as parent)Text v=spf1 mx ip4:217.64.107.106 -all mailText v=spf1 mx ip4:217.64.107.106 -all What is wrong with above ? TIA --- 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. --- 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. --- 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. --- 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. --- 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. --- 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.
RE: [Declude.JunkMail] SPF Issue
What is the issue? What error message? Was it bounced mail? What did the NDR say? I could be a recipient trying to forward mail to another server, or an end-user trying to send email from home using their local ISP... etc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Sunday, August 31, 2008 10:18 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SPF Issue Hi all I have som SPF issues It was working fine some times back I use Mixrosoft dns I have (same as parent)Text v=spf1 mx ip4:217.64.107.106 -all mailText v=spf1 mx ip4:217.64.107.106 -all What is wrong with above ? TIA --- 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. --- 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.
Re[2]: [Declude.JunkMail] SPF Issue
It's a tiny thing - but it might matter: When I dig for your spf record dig @ns1.cefib.com cefib.com -t txt I get: ;; ANSWER SECTION: cefib.com. 3540IN TXT v=spf1 mx ip4:217.64.107.106 -all On the surface it looks correct, but the -all should be ~all That is - it should be a tilde not a dash. Seems like a little thing, but that's also the only thing that doesn't look right when compared to what I get approximating this at openspf.org. Hope this helps, _M On Monday, September 1, 2008, 7:15:35 PM, Serge wrote: S Here is what i get from DNSSTUFF S Not sure what else to do to find out what is going on S How I am searching: S Searching for cefib.com SPF record at f.root-servers.net [192.5.5.241]: Got S referral to D.GTLD-SERVERS.NET. (zone: com.) [took 59 ms] S Searching for cefib.com SPF record at D.GTLD-SERVERS.NET. [192.31.80.30]: S Got referral to ns1.cefib.com. (zone: cefib.com.) [took 31 ms] S Searching for cefib.com SPF record at ns1.cefib.com. [217.64.107.100]: S Reports that no SPF records exist. [took 301 ms] Response: No SPF records S exist for cefib.com. [Neg TTL=3540 seconds] Details: ns1.cefib.com. (an S authoritative nameserver for cefib.com.) says that there are no SPF records S for cefib.com. The E-mail address in charge of the cefib.com. zone is: S [EMAIL PROTECTED] S There is no need to refresh the page -- to see the DNS traversal, to make S sure that all DNS servers are reporting the same results, you can Click S Here. Note that these results are obtained in real-time, meaning that these S are not cached results. These results are what DNS resolvers all over the S world will see right now (unless they have cached information). S - Original Message - S From: Andy Schmidt [EMAIL PROTECTED] S To: declude.junkmail@declude.com S Sent: Monday, September 01, 2008 12:41 PM S Subject: RE: [Declude.JunkMail] SPF Issue What is the issue? What error message? Was it bounced mail? What did the NDR say? I could be a recipient trying to forward mail to another server, or an end-user trying to send email from home using their local ISP... etc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Sunday, August 31, 2008 10:18 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SPF Issue Hi all I have som SPF issues It was working fine some times back I use Mixrosoft dns I have (same as parent)Text v=spf1 mx ip4:217.64.107.106 -all mailText v=spf1 mx ip4:217.64.107.106 -all What is wrong with above ? TIA --- 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. --- 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. S --- S This E-mail came from the Declude.JunkMail mailing list. To S unsubscribe, just send an E-mail to [EMAIL PROTECTED], and S type unsubscribe Declude.JunkMail. The archives can be found S at http://www.mail-archive.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.
Re[2]: [Declude.JunkMail] SPF Issue
Ooops. I take that last post back I found something else looking more closely: ;; ANSWER SECTION: cefib.com. 3540IN TXT v=spf1 mx ip4:217.64.107.106 -all The mx should not be naked. Presumably what you wanted was this: v=spf1 mx:cefib.com ip4:217.64.107.106 ~all Hope this helps, _M On Monday, September 1, 2008, 7:15:35 PM, Serge wrote: S Here is what i get from DNSSTUFF S Not sure what else to do to find out what is going on S How I am searching: S Searching for cefib.com SPF record at f.root-servers.net [192.5.5.241]: Got S referral to D.GTLD-SERVERS.NET. (zone: com.) [took 59 ms] S Searching for cefib.com SPF record at D.GTLD-SERVERS.NET. [192.31.80.30]: S Got referral to ns1.cefib.com. (zone: cefib.com.) [took 31 ms] S Searching for cefib.com SPF record at ns1.cefib.com. [217.64.107.100]: S Reports that no SPF records exist. [took 301 ms] Response: No SPF records S exist for cefib.com. [Neg TTL=3540 seconds] Details: ns1.cefib.com. (an S authoritative nameserver for cefib.com.) says that there are no SPF records S for cefib.com. The E-mail address in charge of the cefib.com. zone is: S [EMAIL PROTECTED] S There is no need to refresh the page -- to see the DNS traversal, to make S sure that all DNS servers are reporting the same results, you can Click S Here. Note that these results are obtained in real-time, meaning that these S are not cached results. These results are what DNS resolvers all over the S world will see right now (unless they have cached information). S - Original Message - S From: Andy Schmidt [EMAIL PROTECTED] S To: declude.junkmail@declude.com S Sent: Monday, September 01, 2008 12:41 PM S Subject: RE: [Declude.JunkMail] SPF Issue What is the issue? What error message? Was it bounced mail? What did the NDR say? I could be a recipient trying to forward mail to another server, or an end-user trying to send email from home using their local ISP... etc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Sunday, August 31, 2008 10:18 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SPF Issue Hi all I have som SPF issues It was working fine some times back I use Mixrosoft dns I have (same as parent)Text v=spf1 mx ip4:217.64.107.106 -all mailText v=spf1 mx ip4:217.64.107.106 -all What is wrong with above ? TIA --- 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. --- 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. S --- S This E-mail came from the Declude.JunkMail mailing list. To S unsubscribe, just send an E-mail to [EMAIL PROTECTED], and S type unsubscribe Declude.JunkMail. The archives can be found S at http://www.mail-archive.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.
Re[3]: [Declude.JunkMail] SPF Issue
The mx should not be naked. Actually, naked mx mechanism is fine. So is -all (deny-all being preferable to anything looser). The cefib.com TXT record is a valid SPF record. The problem is likely to be an NXDOMAIN received by DNSStuff, perhaps due to routing problems. Other remote tests such as Men and Mice's DIG online work fine. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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.
[Declude.JunkMail] SPF Issue
Hi all I have som SPF issues It was working fine some times back I use Mixrosoft dns I have (same as parent)Text v=spf1 mx ip4:217.64.107.106 -all mailText v=spf1 mx ip4:217.64.107.106 -all What is wrong with above ? TIA --- 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.
Re: [Declude.JunkMail] SPF Issue
I have som SPF issues What issues? Did you validate your TXT record at openspf? --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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.
[Declude.JunkMail] SPF (Fail or Pass)
I am not really sure how to set this up but I would like to make sure that if a domain has an spf record that it is checked and if it is not legit it is immediately marked as spam. Also, is it possible to do this on my domain as I get a lot of spoofed email to my domain using my domain as a return address. Thanks for any help offered! Kevin --- 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.
Re: [Declude.JunkMail] SPF (Fail or Pass)
Only SPFFAIL is recommended, as spammers may have SPF records. Also, since many organizations are not using SPF, SPFUNKNOWN is not useful. Here's how you declare it in your GLOBAL.CFG SPFFAILspffailxput your test weight here0 I find that SPF is very useful, if for no other reason than to block spam sent to our customers that forges their domain when sending to them. To create your own SPF records, try http://www.openspf.org/ Darin. - Original Message - From: Kevin Stanford [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Friday, September 07, 2007 9:05 AM Subject: [Declude.JunkMail] SPF (Fail or Pass) I am not really sure how to set this up but I would like to make sure that if a domain has an spf record that it is checked and if it is not legit it is immediately marked as spam. Also, is it possible to do this on my domain as I get a lot of spoofed email to my domain using my domain as a return address. Thanks for any help offered! Kevin --- 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. --- 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.
[Declude.JunkMail] SPF in Imail
I was looking through my settings and noticed that SPF is enabled for Imails anti-spam but all other tests are disabled. I am using Declude junkmail so is there any reason to have SPF enabled for Imail? Mark Reimer IT System Admin American CareSource 972-308-6887 ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
RE: [Declude.JunkMail] SPF in Imail
Until IPswitch offers SPF checking during the connection (where it really belongs), I can't see any benefit of doing that in Imail. Might as well let Declude handle it all and make it part of your weighting scheme. Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark ReimerSent: Thursday, October 26, 2006 04:16 PMTo: Declude JunkMailSubject: [Declude.JunkMail] SPF in Imail I was looking through my settings and noticed that SPF is enabled for Imails anti-spam but all other tests are disabled. I am using Declude junkmail so is there any reason to have SPF enabled for Imail? Mark Reimer IT System Admin American CareSource 972-308-6887 ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com. ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] SPF Hard vs Soft Fail
Nope. Just Pass (Pass or Soft Fail), Fail (Hard Fail), or Unknown (no SPF record). Darin. - Original Message - From: David Dodell [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Sunday, August 20, 2006 11:01 PM Subject: [Declude.JunkMail] SPF Hard vs Soft Fail I couldn't find it in the Declude docs, but is there a test for SPF Hard vs Soft Fail? David --- 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. --- 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.
Re: [Declude.JunkMail] SPF Hard vs Soft Fail
Darin, I don't believe that is correct. The SPFPASS will not be trigged on a soft fail, only if an email actually matches the SPF record, as the SPFFAIL will only be trigged if the email explicitly fails the SPF test. The UNKNOWN will be returned on a soft fail or no SPF record present. So you could use something like this in your global config. SPFFAIL spffailx 2 0 SPFPASS spfpassx -2 0 SPFUNKNOWN spf unknown x 0 0 Dean On 8/21/06, Darin Cox [EMAIL PROTECTED] wrote: Nope. Just Pass (Pass or Soft Fail), Fail (Hard Fail), or Unknown (no SPF record). Darin. - Original Message - From: David Dodell [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Sunday, August 20, 2006 11:01 PM Subject: [Declude.JunkMail] SPF Hard vs Soft Fail I couldn't find it in the Declude docs, but is there a test for SPF Hard vs Soft Fail? David --- 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. --- 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. -- __ Dean Lawrence, CIO/Partner Internet Data Technology 888.GET.IDT1 ext. 701 * fax: 888.438.4381 http://www.idatatech.com/ Corporate Internet Development and Marketing Specialists --- 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.
Re: [Declude.JunkMail] SPF Hard vs Soft Fail
Sorry, you're correct. The answer is still no, however. It is not currently possible to capture Soft Fail, so there's no way to test Soft Fail vs. Hard Fail. Darin. - Original Message - From: Dean Lawrence [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Monday, August 21, 2006 11:29 AM Subject: Re: [Declude.JunkMail] SPF Hard vs Soft Fail Darin, I don't believe that is correct. The SPFPASS will not be trigged on a soft fail, only if an email actually matches the SPF record, as the SPFFAIL will only be trigged if the email explicitly fails the SPF test. The UNKNOWN will be returned on a soft fail or no SPF record present. So you could use something like this in your global config. SPFFAIL spf fail x 2 0 SPFPASS spf pass x -2 0 SPFUNKNOWN spf unknown x 0 0 Dean On 8/21/06, Darin Cox [EMAIL PROTECTED] wrote: Nope. Just Pass (Pass or Soft Fail), Fail (Hard Fail), or Unknown (no SPF record). Darin. - Original Message - From: David Dodell [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Sunday, August 20, 2006 11:01 PM Subject: [Declude.JunkMail] SPF Hard vs Soft Fail I couldn't find it in the Declude docs, but is there a test for SPF Hard vs Soft Fail? David --- 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. --- 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. -- __ Dean Lawrence, CIO/Partner Internet Data Technology 888.GET.IDT1 ext. 701 * fax: 888.438.4381 http://www.idatatech.com/ Corporate Internet Development and Marketing Specialists --- 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. --- 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.
[Declude.JunkMail] SPF Hard vs Soft Fail
I couldn't find it in the Declude docs, but is there a test for SPF Hard vs Soft Fail? David --- 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.
[Declude.JunkMail] SPF tests in Declude
I've seen all the talk for and against SPF on this list, and I've been trying to decide how much weight I want to give SPF. (I'm currently using Declude 3.0.6.4 and SmarterMail 2.6). I started playing around with SmarterMail's SPF tags by setting them to a low or zero weight just so I could see the tags in the headers and get an idea as to how much spam was passing, and how much ham was failing.Then I started to think about Declude. For some reason I had assumed that Declude's SPF tests were commented out in my config files. I checked and found that I was wrong. In my global.cfg file, there was the following: SPFFAIL spffail x x 3 0 SPFPASS spfpass x x -3 0 and in my $default$.junkmail file there was SPFFAIL WARN SPFPASS WARN yet I have never seen in the header of any message a tag from Declude that said anything about SPF. I do see tags from SmarterMail like SPF_Pass, SPF_Neutral and SPF_None. I am I missing something here? Do these tests work in Declude? Is there some other statement I need in my config files for these tests to work? Thanks in advance, Gary --- 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.
Re: [Declude.JunkMail] SPF tests in Declude
Many spammers have an SPF record. So the SPFPASS deserves no negative weight. I have SPFPASS set at zero Here's my settings: SPFPASS spf pass x 0 0 SPFUNKNOWN spf unknown x 0 0 SPFFAIL spf fail x 50 0 - Original Message - From: Gary Steiner [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, March 30, 2006 6:36 PM Subject: [Declude.JunkMail] SPF tests in Declude I've seen all the talk for and against SPF on this list, and I've been trying to decide how much weight I want to give SPF. (I'm currently using Declude 3.0.6.4 and SmarterMail 2.6). I started playing around with SmarterMail's SPF tags by setting them to a low or zero weight just so I could see the tags in the headers and get an idea as to how much spam was passing, and how much ham was failing.Then I started to think about Declude. For some reason I had assumed that Declude's SPF tests were commented out in my config files. I checked and found that I was wrong. In my global.cfg file, there was the following: SPFFAIL spffail x x 3 0 SPFPASS spfpass x x -3 0 and in my $default$.junkmail file there was SPFFAIL WARN SPFPASS WARN yet I have never seen in the header of any message a tag from Declude that said anything about SPF. I do see tags from SmarterMail like SPF_Pass, SPF_Neutral and SPF_None. I am I missing something here? Do these tests work in Declude? Is there some other statement I need in my config files for these tests to work? Thanks in advance, Gary --- 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. --- 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.
Re: [Declude.JunkMail] SPF tests in Declude
I assume the values I show are the default ones that came with Declude. However, that's not my issue. The values are meaningless if the test is not working. I'm not even sure that Delude is using these values, since I never see a Declude SPF tag in a message header. Do your tests show up in your message headers? As an aside, I've seen many non-spammers failing the SmarterMail SPF check, and few spammers passing it. Original Message From: Scott Fisher [EMAIL PROTECTED] Sent: Thursday, March 30, 2006 8:35 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF tests in Declude Many spammers have an SPF record. So the SPFPASS deserves no negative weight. I have SPFPASS set at zero Here's my settings: SPFPASS spf pass x 0 0 SPFUNKNOWN spf unknown x 0 0 SPFFAIL spf fail x 50 0 - Original Message - From: Gary Steiner [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, March 30, 2006 6:36 PM Subject: [Declude.JunkMail] SPF tests in Declude I've seen all the talk for and against SPF on this list, and I've been trying to decide how much weight I want to give SPF. (I'm currently using Declude 3.0.6.4 and SmarterMail 2.6). I started playing around with SmarterMail's SPF tags by setting them to a low or zero weight just so I could see the tags in the headers and get an idea as to how much spam was passing, and how much ham was failing.Then I started to think about Declude. For some reason I had assumed that Declude's SPF tests were commented out in my config files. I checked and found that I was wrong. In my global.cfg file, there was the following: SPFFAIL spffail x x 3 0 SPFPASS spfpass x x -3 0 and in my $default$.junkmail file there was SPFFAIL WARN SPFPASS WARN yet I have never seen in the header of any message a tag from Declude that said anything about SPF. I do see tags from SmarterMail like SPF_Pass, SPF_Neutral and SPF_None. I am I missing something here? Do these tests work in Declude? Is there some other statement I need in my config files for these tests to work? Thanks in advance, Gary --- 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.
RE: [Declude.JunkMail] SPF tests in Declude
There is currently a bug in decludes spf test where is can show a SPFFAIL when it should show SPFPASS. I have already notified Declude and shen them logs from a special debug version of Declude Junkmail Kevin Bilbee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Steiner Sent: Thursday, March 30, 2006 5:49 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF tests in Declude I assume the values I show are the default ones that came with Declude. However, that's not my issue. The values are meaningless if the test is not working. I'm not even sure that Delude is using these values, since I never see a Declude SPF tag in a message header. Do your tests show up in your message headers? As an aside, I've seen many non-spammers failing the SmarterMail SPF check, and few spammers passing it. Original Message From: Scott Fisher [EMAIL PROTECTED] Sent: Thursday, March 30, 2006 8:35 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF tests in Declude Many spammers have an SPF record. So the SPFPASS deserves no negative weight. I have SPFPASS set at zero Here's my settings: SPFPASS spf pass x 0 0 SPFUNKNOWN spf unknown x 0 0 SPFFAIL spf fail x 50 0 - Original Message - From: Gary Steiner [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, March 30, 2006 6:36 PM Subject: [Declude.JunkMail] SPF tests in Declude I've seen all the talk for and against SPF on this list, and I've been trying to decide how much weight I want to give SPF. (I'm currently using Declude 3.0.6.4 and SmarterMail 2.6). I started playing around with SmarterMail's SPF tags by setting them to a low or zero weight just so I could see the tags in the headers and get an idea as to how much spam was passing, and how much ham was failing.Then I started to think about Declude. For some reason I had assumed that Declude's SPF tests were commented out in my config files. I checked and found that I was wrong. In my global.cfg file, there was the following: SPFFAIL spffail x x 3 0 SPFPASS spfpass x x -3 0 and in my $default$.junkmail file there was SPFFAIL WARN SPFPASS WARN yet I have never seen in the header of any message a tag from Declude that said anything about SPF. I do see tags from SmarterMail like SPF_Pass, SPF_Neutral and SPF_None. I am I missing something here? Do these tests work in Declude? Is there some other statement I need in my config files for these tests to work? Thanks in advance, Gary --- 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. --- 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.
Re: [Declude.JunkMail] SPF tests in Declude
I couldn't see the forest for the trees. After digging through the archive of this mailing list, I finally figured out that Scott's example had an extra space and one less x. I had assumed the the default format that was installed with Declude was correct. Now I will have to check the other tests that I haven't paid much attention but assumed the default was correct. Thanks Scott, and all the others who patiently gave the answer in the past. Gary Original Message From: Gary Steiner [EMAIL PROTECTED] Sent: Thursday, March 30, 2006 8:51 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF tests in Declude I assume the values I show are the default ones that came with Declude. However, that's not my issue. The values are meaningless if the test is not working. I'm not even sure that Delude is using these values, since I never see a Declude SPF tag in a message header. Do your tests show up in your message headers? As an aside, I've seen many non-spammers failing the SmarterMail SPF check, and few spammers passing it. Original Message From: Scott Fisher [EMAIL PROTECTED] Sent: Thursday, March 30, 2006 8:35 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF tests in Declude Many spammers have an SPF record. So the SPFPASS deserves no negative weight. I have SPFPASS set at zero Here's my settings: SPFPASS spf pass x 0 0 SPFUNKNOWN spf unknown x 0 0 SPFFAIL spf fail x 50 0 - Original Message - From: Gary Steiner [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, March 30, 2006 6:36 PM Subject: [Declude.JunkMail] SPF tests in Declude I've seen all the talk for and against SPF on this list, and I've been trying to decide how much weight I want to give SPF. (I'm currently using Declude 3.0.6.4 and SmarterMail 2.6). I started playing around with SmarterMail's SPF tags by setting them to a low or zero weight just so I could see the tags in the headers and get an idea as to how much spam was passing, and how much ham was failing.Then I started to think about Declude. For some reason I had assumed that Declude's SPF tests were commented out in my config files. I checked and found that I was wrong. In my global.cfg file, there was the following: SPFFAIL spffail x x 3 0 SPFPASS spfpass x x -3 0 and in my $default$.junkmail file there was SPFFAIL WARN SPFPASS WARN yet I have never seen in the header of any message a tag from Declude that said anything about SPF. I do see tags from SmarterMail like SPF_Pass, SPF_Neutral and SPF_None. I am I missing something here? Do these tests work in Declude? Is there some other statement I need in my config files for these tests to work? Thanks in advance, Gary --- 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.
RE: Re[2]: [Declude.JunkMail] spf breaks email forwarding -
Thanks, Sandy. I liked this approach for a couple of reasons; off the top of my head: 1) I was sure that Declude locks the Q*.SMD file (if for no other reason than to stop Imail from poaching them) and possibly the D*.SMD file so I thought an external test wouldn't be able to redirect them. 2) I wanted to leave the option open to rewrite the D*.SMD file, such as inserting a custom header line. 3) Configuration would be very easy. For example, each time a Program Alias is created in IMail, the first two parameters could be the destination at my domain and the destination at the forwarded domain; when the script or program is called, it is provided with the hardcoded from and to addresses and then the name of tmp*.tmp file (which is really a D*.SMD file). 4) The DAISYCHAIN directive has received little attention in the years I've been using Declude with IMail, so it's probably not a good feature to rely on if I spec'ed this to be an external program that would run after Declude and change the queuing behaviour. 5) It makes the assumption that the other Declude filters and antispamming can go ahead as planned; I didn't have to think about the law of unintended consequences. 6) That previous item expands to my trying to write a two part solution where an external filter creates the correct condition, and then a doesn't-scale-well Declude filter test plus action to COPYTO [EMAIL PROTECTED] lines 7) I had already downloaded one of the official distributions of source code for SRS and it made my eyes swim; it was pretty clear that SRS tackles a much larger problem than the envelope re-writing I could almost reach this way. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman Sent: Tuesday, March 07, 2006 6:37 PM To: Colbeck, Andrew Subject: Re[2]: [Declude.JunkMail] spf breaks email forwarding - If you want to perservere and build your own forwarding system, what I found was that. . . Andrew, I like your workaround with the Program Alias. However, I think that instead, if people are willing to wait a few weeks to a month, I can find time to put out a full-fledged external test for Declude that does much the same thing, without having to forge brand-new Q files and so on, honoring IMail-level forwards. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/do wnload/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2a liases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2alias es/download/release/ --- 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. --- 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.
Re: [Declude.JunkMail] spf breaks email forwarding -
Wow thanks for the efforts here Andrew - Nice work! -Nick Colbeck, Andrew wrote: Hey, Nick. I spent some timepoking at this with a stick. Since I just use IMail as a gateway so that I can use Declude... I've had no use for IMail mailboxes or forwarding, so it was all new to me. The real answer is that you should lobby Ipswitch to implement that sender re-writing in their forwarding (what the heck... all of SPF plus the bells and whistles while they're at it). If you can garner support from other people to make the same request, all the better. You can also tell your client "Sorry, Adelphia controls how [EMAIL PROTECTED] email is moved around and since the destination you want adheres to Adelphia's wishes,I can't forward it. However, if you do have Adelpha forward the mail to me, I can filter out the spam and viruses, and you can use POP/IMAP to retrievethe good mailfrom my server." As a new policy, you would want to double-check that any mailbox for which you do forwarding doesn't send mail from some domain that has a tight SPF, or whomever you're fowarding to (e.g. surfglobal.net) will see you as a spammer. If you want to perservere and build your own forwarding system, what I found was that: 1) Just doing a "forward" action on a mailbox was functionally identical to making an IMailmailbox with a rule that says "if sender email contains '@' then forward the mail to [EMAIL PROTECTED]" and that this forwardingviolates SPF for a domain like Adelphia.com. 2) It's not easy but it's not impossible to instead use a Program Alias instead. That program alias would call a batch file with optional parameters (let's say we provide two in our configuration). That batch then receives a %3 parameter added on that contains a tmp*.tmp filename which isreally a D*.SMD file with a different name in the \imail\spool folder. The first thing the batch would do is some sanity checks. You would have to avoid mail loops and other badnessby making sure that this is a message that should be forwarded, e.g. not a bounce message from whomever you're forwarding messages to! If it is crap, it should delete the tmp*.tmp file and exit. The second thing the script would do is manufacture a Q*.SMD file. Since you've already got the D*.SMD file, if you can just manufacture an appropriate Q*.SMD file, you can have IMail re-send the message while passing on the complete headers and without having to do any editing of the D*.SMD file although there probably are useful smarty pants edits (e.g. changing the "From:" line to something like "From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]" orinserting the frills Received-SPF: header). Here's the format of the Q*.SMD file, as per the venerable R. Scott Perry: http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html The "S" sender row would normally be[EMAIL PROTECTED] but that violates SPF, so you instead specify [EMAIL PROTECTED] there. The "R" recipient row would then be the 3rd party destination, e.g. [EMAIL PROTECTED] In my testing it seemed that also using the "N" original recipient row to the sender field would preserve the "Reply-To:" as the original sender but that may have been an artifact of bad thinking on my part (you'd best extract the original Declude spoolname from the tmp*.tmp file and use that to extract the MAILFROM for that message from the sys*.txt file! [To get that, you must use the "XSENDERON" option in your global.cfg file]) The "Q" file row defines the fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD format; you can just specify the tmp*.tmp file here. The "H" host row is just your normal name for the IMail host. The "I" guid row contains the long id number that IMail will use in the sys*.txt file to identify this message. Ideally this would be unique every time; however for testing you could write out the same row every time. Here's a sample: QC:\IMail\spool\tmp1B.tmp Hmail.madriver.com Ic507787800822fbd WC:\IMail S[EMAIL PROTECTED] NRCPT TO:[EMAIL PROTECTED] R[EMAIL PROTECTED] The third thing the script would dois tohave IMail deliver the message. Here's how to re-queue a single Q*.SMD + D*.SMD pair: http://support.ipswitch.com/kb/IM-2623-DM02.htm The short version being that if you make sure that the Q*.SMD file (which can be any filename) contains the "Q" row and a fully qualified D*.SMD file (which can be any filename) you can just call: smtp32.exe Qxxx.SMD and IMail will queue it up immediately. Ta-dah! Easy as world peace. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 1:13 PM To: Declude.JunkMa
Re: [Declude.JunkMail] spf breaks email forwarding -
Hi Sandy Sanford Whiteman wrote: Andrew, I like your workaround with the Program Alias. However, I think that instead, if people are willing to wait a few weeks to a month, I can find time to put out a full-fledged external test for Declude that does much the same thing, without having to forge brand-new Q files and so on, honoring IMail-level forwards. Although I am going to give Andrew's tactic a try now I would very much appreciate your external test when it becomes available. Thanks! -Nick --- 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.
Re[3]: [Declude.JunkMail] spf breaks email forwarding -
On 11:39 PM 3/6/2006 -0500, it would appear that Sanford Whiteman wrote: Sure it is, SPF is NOT an RFC and if the email follows RFC then it is legit. I'm afraid you have a rather exaggerated opinion of the relevance of RFCs, and of the concept of domain ownership. RFCs are meaningless when it comes to the acceptable use of your domain (which is protected by law, not at all by RFC). . . not to mention that the SMTP RFCs are widely disregarded in spamfighting: I'm sure you have several policies which do not respect all RFC MUSTs and SHOULDs. Please don't assume that you have any idea how my policies are set. The courts have affirmed that a domain owner solely controls the use of the domain, even if it is not a distinctly registered trade or service mark (US Code Title 15, Chapter 22, Subchapter III, § 1127). Anyone else is simply using the mark at the will of the owner and is not protected any way by RFC. US Code v. RFC = no contest! Good to know, next time I have to make sure that my servers can communicate properly with the rest of the world, I'll be sure to check the relevant case law first. After all, I'm sure the courts will help me do a much better job than by following the RFCs. Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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.
Re[4]: [Declude.JunkMail] spf breaks email forwarding -
Please don't assume that you have any idea how my policies are set. I'm not assuming: you've made some of them public. For example, you touted day-of-week and hour tests as effective gauges of spamminess. Note that I don't disagree at all with your conclusions about these tests. I mention such positions to show that they are certainly counter to your prior claim that RFC-compliance alone ensures legitimacy. More important, since it would be impossible to get real effectiveness out of any anti-spam solution without following internal policies that countermand RFC compliance, it is safe to say that _everyone_ who is satisfied with Declude does not treat the RFC compliance of incoming sessions/messages as grounds for whitelisting! You simply wouldn't be here if you took that much stock in RFCs; it doesn't matter that you haven't revealed your whole config. AFAIK, the only people who treat the RFCs with that much respect are the academic anti-spam-is-fascism advocates (at least, those few who are actually sincere and not trolls for the direct matrketing industry). Good to know, next time I have to make sure that my servers can communicate properly with the rest of the world, I'll be sure to check the relevant case law first. After all, I'm sure the courts will help me do a much better job than by following the RFCs. Don't really see much there to mock, but knock yourself out. US Code protects your right to restrict the use of domains you own in any MAIL FROM. The law therefore protects your ability to publish policies for your domain that are expressly intended to affect how and where non-owners of your domain may use the domain, as long as (and I did mention this caveat before) such protection does not contradict a right expressly granted by a separate contract. There is no generic, assumed right that a non-owner has to the use of a domain. Look, I know you're very put out by SPF. You know you don't have the kind of userbase, and the kind of relationship with your users, that would let you publish a policy. That's just fine. I have clients that can't publish SPF either, so I'm not telling you that you have to find a way to make it work. I'm telling you that it does work for some very significant domains, domains with very large legal departments at that, and there is no legal argument against it. There may be an RFC argument against it -- *if* in every area you treat RFC-compliant senders as trusted senders. But I think due to the nature of this mailing list, there is a justifiable presumption of guilt in that department. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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.
RE: [Declude.JunkMail] spf breaks email forwarding -
Hey, Nick. I spent some timepoking at this with a stick. Since I just use IMail as a gateway so that I can use Declude... I've had no use for IMail mailboxes or forwarding, so it was all new to me. The real answer is that you should lobby Ipswitch to implement that sender re-writing in their forwarding (what the heck... all of SPF plus the bells and whistles while they're at it). If you can garner support from other people to make the same request, all the better. You can also tell your client "Sorry, Adelphia controls how [EMAIL PROTECTED] email is moved around and since the destination you want adheres to Adelphia's wishes,I can't forward it. However, if you do have Adelpha forward the mail to me, I can filter out the spam and viruses, and you can use POP/IMAP to retrievethe good mailfrom my server." As a new policy, you would want to double-check that any mailbox for which you do forwarding doesn't send mail from some domain that has a tight SPF, or whomever you're fowarding to (e.g. surfglobal.net) will see you as a spammer. If you want to perservere and build your own forwarding system, what I found was that: 1) Just doing a "forward" action on a mailbox was functionally identical to making an IMailmailbox with a rule that says "if sender email contains '@' then forward the mail to [EMAIL PROTECTED]" and that this forwardingviolates SPF for a domain like Adelphia.com. 2) It's not easy but it's not impossible to instead use a Program Alias instead. That program alias would call a batch file with optional parameters (let's say we provide two in our configuration). That batch then receives a %3 parameter added on that contains a tmp*.tmp filename which isreally a D*.SMD file with a different name in the \imail\spool folder. The first thing the batch would do is some sanity checks. You would have to avoid mail loops and other badnessby making sure that this is a message that should be forwarded, e.g. not a bounce message from whomever you're forwarding messages to! If it is crap, it should delete the tmp*.tmp file and exit. The second thing the script would do is manufacture a Q*.SMD file. Since you've already got the D*.SMD file, if you can just manufacture an appropriate Q*.SMD file, you can have IMail re-send the message while passing on the complete headers and without having to do any editing of the D*.SMD file although there probably are useful smarty pants edits (e.g. changing the "From:" line to something like "From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]" orinserting the frills Received-SPF: header). Here's the format of the Q*.SMD file, as per the venerable R. Scott Perry: http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html The "S" sender row would normally be[EMAIL PROTECTED] but that violates SPF, so you instead specify [EMAIL PROTECTED] there. The "R" recipient row would then be the 3rd party destination, e.g. [EMAIL PROTECTED] In my testing it seemed that also using the "N" original recipient row to the sender field would preserve the "Reply-To:" as the original sender but that may have been an artifact of bad thinking on my part (you'd best extract the original Declude spoolname from the tmp*.tmp file and use that to extract the MAILFROM for that message from the sys*.txt file! [To get that, you must use the "XSENDERON" option in your global.cfg file]) The "Q" file row defines the fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD format; you can just specify the tmp*.tmp file here. The "H" host row is just your normal name for the IMail host. The "I" guid row contains the long id number that IMail will use in the sys*.txt file to identify this message. Ideally this would be unique every time; however for testing you could write out the same row every time. Here's a sample: QC:\IMail\spool\tmp1B.tmpHmail.madriver.comIc507787800822fbdWC:\IMailS[EMAIL PROTECTED]NRCPT TO:[EMAIL PROTECTED]R[EMAIL PROTECTED] The third thing the script would dois tohave IMail deliver the message. Here's how to re-queue a single Q*.SMD + D*.SMD pair: http://support.ipswitch.com/kb/IM-2623-DM02.htm The short version being that if you make sure that the Q*.SMD file (which can be any filename) contains the "Q" row and a fully qualified D*.SMD file (which can be any filename) you can just call: smtp32.exe Qxxx.SMD and IMail will queue it up immediately. Ta-dah! Easy as world peace. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick HayerSent: Saturday, March 04, 2006 1:13 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] spf breaks email forwarding - Matt wrote: Real-world issues include working around bad implementation, such as surfglobal.net
Re[2]: [Declude.JunkMail] spf breaks email forwarding -
If you want to perservere and build your own forwarding system, what I found was that. . . Andrew, I like your workaround with the Program Alias. However, I think that instead, if people are willing to wait a few weeks to a month, I can find time to put out a full-fledged external test for Declude that does much the same thing, without having to forge brand-new Q files and so on, honoring IMail-level forwards. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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.
Re: [Declude.JunkMail] spf breaks email forwarding -
since the destination you want adheres to Adelphia's wishes,I can't forward it. However, if you do have Adelpha forward the mail to me, I can filter out the spam and viruses, and you can use POP/IMAP to retrievethe good mailfrom my server." As a new policy, you would want to double-check that any mailbox for which you do forwarding doesn't send mail from some domain that has a tight SPF, or whomever you're fowarding to (e.g. surfglobal.net) will see you as a spammer. If you want to perservere and build your own forwarding system, what I found was that: 1) Just doing a "forward" action on a mailbox was functionally identical to making an IMailmailbox with a rule that says "if sender email contains '@' then forward the mail to [EMAIL PROTECTED]" and that this forwardingviolates SPF for a domain like Adelphia.com. 2) It's not easy but it's not impossible to instead use a Program Alias instead. That program alias would call a batch file with optional parameters (let's say we provide two in our configuration). That batch then receives a %3 parameter added on that contains a tmp*.tmp filename which isreally a D*.SMD file with a different name in the \imail\spool folder. The first thing the batch would do is some sanity checks. You would have to avoid mail loops and other badnessby making sure that this is a message that should be forwarded, e.g. not a bounce message from whomever you're forwarding messages to! If it is crap, it should delete the tmp*.tmp file and exit. The second thing the script would do is manufacture a Q*.SMD file. Since you've already got the D*.SMD file, if you can just manufacture an appropriate Q*.SMD file, you can have IMail re-send the message while passing on the complete headers and without having to do any editing of the D*.SMD file although there probably are useful smarty pants edits (e.g. changing the "From:" line to something like "From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]" orinserting the frills Received-SPF: header). Here's the format of the Q*.SMD file, as per the venerable R. Scott Perry: http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html The "S" sender row would normally be[EMAIL PROTECTED] but that violates SPF, so you instead specify [EMAIL PROTECTED] there. The "R" recipient row would then be the 3rd party destination, e.g. [EMAIL PROTECTED] In my testing it seemed that also using the "N" original recipient row to the sender field would preserve the "Reply-To:" as the original sender but that may have been an artifact of bad thinking on my part (you'd best extract the original Declude spoolname from the tmp*.tmp file and use that to extract the MAILFROM for that message from the sys*.txt file! [To get that, you must use the "XSENDERON" option in your global.cfg file]) The "Q" file row defines the fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD format; you can just specify the tmp*.tmp file here. The "H" host row is just your normal name for the IMail host. The "I" guid row contains the long id number that IMail will use in the sys*.txt file to identify this message. Ideally this would be unique every time; however for testing you could write out the same row every time. Here's a sample: QC:\IMail\spool\tmp1B.tmp Hmail.madriver.com Ic507787800822fbd WC:\IMail S[EMAIL PROTECTED] NRCPT TO:[EMAIL PROTECTED] R[EMAIL PROTECTED] The third thing the script would dois tohave IMail deliver the message. Here's how to re-queue a single Q*.SMD + D*.SMD pair: http://support.ipswitch.com/kb/IM-2623-DM02.htm The short version being that if you make sure that the Q*.SMD file (which can be any filename) contains the "Q" row and a fully qualified D*.SMD file (which can be any filename) you can just call: smtp32.exe Qxxx.SMD and IMail will queue it up immediately. Ta-dah! Easy as world peace. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 1:13 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] spf breaks email forwarding - Matt wrote: Real-world issues include working around bad implementation, such as surfglobal.net not configuring their server to reject messages that fail SPF. SRS is a work around - and I'm simply asking if anyone has implemented it on an Imail/Declude platform. Kindly stay on topic I am aware of your feelings about SPF - all I'm doing is working out a solution with what is in place - an MTA bouncing my legit email. I suggest you tell your customer that they can't forward their E-mail reliably unless surfglobal.net removes their SPF restrictions, and there is nothing that you can do about it.
Re[2]: [Declude.JunkMail] spf breaks email forwarding -
Back to SRS. SRS isn't just simply changing the Mail From address, it is a system that requires both the encoding and parsing of the Mail From addresses, and it requires both the sending and receiving MTA to be SRS aware. The following is from what is apparently the master SRS document. . . I'm not going for an SRS implementation, but a simple method of performing server-side envelope sender address rewriting. The implementation is not intended for use by dedicated forwarders, who must by necessity assume the pass-through of both messages and DSNs. Rather, it is intended for mailbox providers to pre-fetch IMail account- and mailbox-level forwards and rewrite accordingly. Things will break: bounces of forwarded mail will not be returned to the original sender, and this breakage is by design. But SPF 1.0 checks will pass, which is the matter under discussion. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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.
Re: Re[2]: [Declude.JunkMail] spf breaks email forwarding -
Couldn't you get around this whole issue by just adding the forwarding server to the SPF record? Dean On 3/5/06, Sanford Whiteman [EMAIL PROTECTED] wrote: Perfectly legit email - my spf recs are perfect etc.No,it's*not*legit!Domainowners set SPF policies that dictate legitimacy.Thisistheirright.SMTPserverowners respect SPFpolicies. This is my obligation. If Adelphia sets a strict SPF policy,andSurfGlobal respects it, so what? Don't assume that just because a userthinkstheirmailshouldgothrough,thatthemail looksuncontroversial, that the user is right.Ifadomainownersetsa policy that says, Mail with an envelopesender of @ example.com must only come from these servers, sure, maybethatpolicywillprove unworkable later on. Maybe they didn't thinkenoughabout server-level redirection (unlikely, since Adelphia isn't exactlyatinycompany).Maybethey'll change their policies onceusersstartgettingtheirmail rejected (possible, with sufficientoutcry).Butthis all isn't your problem. If you're originating mail thatfails the domain owner's policy, what's the big surprise that itgets bounced? I sure as heck would hope that it got bounced, if I werethedomainowner!Myusersdon'thavetherighttohave this restrictioncompletelyignored,though they may rightly dispute theresultant rejections.YourMTAbreaks the policy with its built-in forwarding function, soifyoudon'twanttochangeyourforwardingfunctionality, put togetheranice helpfile on your forwarding page (just like the kindofthingyoumay have put together to inform people that they can'tforwardtoAOL)thatwarns them that the forwarded messages may be bouncedback to the senders if the senders have restrictive policies.It shouldn't be difficult to articulate in userspeak: If some of yourfriends or associates' ISPs allow them to send mail only _directly_ to otheraddresses,you won't be able to 'relay' or 'zig-zag' that mailthroughyourMadRiverAccessaccounttothe final destination.Restrictionslikethisare placed by your friend's ISP or employer, notbyMRA! We'd be very happy to forward the mail, but your friendsaren't allowed to use this service.Recommendthatthey keep a copy on your server as a fallback againstsuchsituations(agingtheseout,ofcourse, if it's otherwise a globalforward).*Let* the SPF failures keep getting bounced back tothesenders.That's the only way anyone is going to be made aware ofthe possible problem with their SPF policy.But if you do want to change your forwarding policy, it wouldn't be as difficultasimplementing SRS or any of that. You could write a veryeasyscript to change the envelope sender to the local user. It wouldactlikeaclient-side FW: in that respect. The bounces may stay on yourserver,whichisn'tfull service. But it gets the job done.Well-documented,thiswouldbeaperfectlyreasonable option forusers.I have never, not once, ever, had any issues rejecting on SPF. I catch thousandsofmessagesaday.Thereare no false positives. Therecannot be, unless your SPF library has bugs.--SandySanford Whiteman, Chief Technologist Broadleaf Systems, a division ofCypress Integrated Systems, Inc.e-mail: [EMAIL PROTECTED]SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ ---This E-mail came from the Declude.JunkMail mailing list.Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype unsubscribe Declude.JunkMail .The archives can be foundat http://www.mail-archive.com.-- __Dean Lawrence, CIO/Partner Internet Data Technology888.GET.IDT1 ext. 701 * fax: 888.438.4381http://www.idatatech.com/Corporate Internet Development and Marketing Specialists
Re[2]: [Declude.JunkMail] spf breaks email forwarding -
On 08:54 PM 3/5/2006 -0500, it would appear that Sanford Whiteman wrote: Perfectly legit email - my spf recs are perfect etc. No, it's *not* legit! Sure it is, SPF is NOT an RFC and if the email follows RFC then it is legit. My users don't have the right to have this restriction completely ignored, though they may rightly dispute the resultant rejections. If your users are employees, then you are correct. If your users are customers, then you are wrong. Paying customers have a right to expect services to conform to accepted RFCs. SPF breaks multiple RFCs (974 and 2821 come immediately to mind). Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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.
Re[3]: [Declude.JunkMail] spf breaks email forwarding -
Sure it is, SPF is NOT an RFC and if the email follows RFC then it is legit. I'm afraid you have a rather exaggerated opinion of the relevance of RFCs, and of the concept of domain ownership. RFCs are meaningless when it comes to the acceptable use of your domain (which is protected by law, not at all by RFC). . . not to mention that the SMTP RFCs are widely disregarded in spamfighting: I'm sure you have several policies which do not respect all RFC MUSTs and SHOULDs. The courts have affirmed that a domain owner solely controls the use of the domain, even if it is not a distinctly registered trade or service mark (US Code Title 15, Chapter 22, Subchapter III, § 1127). Anyone else is simply using the mark at the will of the owner and is not protected any way by RFC. US Code v. RFC = no contest! If your users are employees, then you are correct. If your users are customers, then you are wrong. Paying customers have a right to expect services to conform to accepted RFCs. Use of a domain is dictated by the domain owner, not by people who are customers, employees, or in any other way using the domain with the consent of the owner. True, _if_ an ISP's EULA should warrant that no measures will be taken to block the use of the domain name by the non-owners, then of course it would be an illegal trade practice to then make actionable moves toward such restrictions (such as publishing an SPF policy) without revising and publicizing a new EULA. But no one would be so stupid as to make such a declaration with any enforceable wording -- I've never seen anything close. You're imagining a level of end-user protection which simply is not generally recognized, though it may exist if literalized in a specific contract. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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.
Re[2]: [Declude.JunkMail] spf breaks email forwarding -
Perfectly legit email - my spf recs are perfect etc. No, it's *not* legit! Domain owners set SPF policies that dictate legitimacy. This is their right. SMTP server owners respect SPF policies. This is my obligation. If Adelphia sets a strict SPF policy, and SurfGlobal respects it, so what? Don't assume that just because a user thinks their mail should go through, that the mail looks uncontroversial, that the user is right. If a domain owner sets a policy that says, Mail with an envelope sender of @example.com must only come from these servers, sure, maybe that policy will prove unworkable later on. Maybe they didn't think enough about server-level redirection (unlikely, since Adelphia isn't exactly a tiny company). Maybe they'll change their policies once users start getting their mail rejected (possible, with sufficient outcry). But this all isn't your problem. If you're originating mail that fails the domain owner's policy, what's the big surprise that it gets bounced? I sure as heck would hope that it got bounced, if I were the domain owner! My users don't have the right to have this restriction completely ignored, though they may rightly dispute the resultant rejections. Your MTA breaks the policy with its built-in forwarding function, so if you don't want to change your forwarding functionality, put together a nice helpfile on your forwarding page (just like the kind of thing you may have put together to inform people that they can't forward to AOL) that warns them that the forwarded messages may be bounced back to the senders if the senders have restrictive policies. It shouldn't be difficult to articulate in userspeak: If some of your friends or associates' ISPs allow them to send mail only _directly_ to other addresses, you won't be able to 'relay' or 'zig-zag' that mail through your Mad River Access account to the final destination. Restrictions like this are placed by your friend's ISP or employer, not by MRA! We'd be very happy to forward the mail, but your friends aren't allowed to use this service. Recommend that they keep a copy on your server as a fallback against such situations (aging these out, of course, if it's otherwise a global forward). *Let* the SPF failures keep getting bounced back to the senders. That's the only way anyone is going to be made aware of the possible problem with their SPF policy. But if you do want to change your forwarding policy, it wouldn't be as difficult as implementing SRS or any of that. You could write a very easy script to change the envelope sender to the local user. It would act like a client-side FW: in that respect. The bounces may stay on your server, which isn't full service. But it gets the job done. Well-documented, this would be a perfectly reasonable option for users. I have never, not once, ever, had any issues rejecting on SPF. I catch thousands of messages a day. There are no false positives. There cannot be, unless your SPF library has bugs. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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.
[Declude.JunkMail] spf breaks email forwarding -
Email customers that forward through me are getting their email bounced because of the original sending domain's spf policy. I understand this delima is addressed with Sender Rewriting Scheme http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude Imail? Thanks -Nick --- 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.
RE: [Declude.JunkMail] spf breaks email forwarding -
I think the underlying problem as has been discussed on this list is that an SPF FAIL should not be relied upon as an outright rejection, rather used as part of a weighting system. John T eServices For You Seek, and ye shall find! -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 11:40 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] spf breaks email forwarding - Email customers that forward through me are getting their email bounced because of the original sending domain's spf policy. I understand this delima is addressed with Sender Rewriting Scheme http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude Imail? Thanks -Nick --- 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. --- 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.
Re: [Declude.JunkMail] spf breaks email forwarding -
I'm not aware of any mail server that supports the Sender Rewriting Scheme. It's certainly a fine idea, but the real issue is that the SPF implementation has issues with forwarded E-mail, and they are seeking to have mail servers correct their shortcoming. It may be a very long-time in coming if it ever gets here at all. IMO, real-world issues demand real-world solutions. Matt Nick Hayer wrote: Email customers that forward through me are getting their email bounced because of the original sending domain's spf policy. I understand this delima is addressed with Sender Rewriting Scheme http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude Imail? Thanks -Nick --- 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. --- 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.
Re: [Declude.JunkMail] spf breaks email forwarding -
The problem is not anything I am doing - it with SPF itself. By design forwarded email will bounce if the receiving MTA is configed that way. Even if I whitelist the emails they will bounce... Let me explain - user@Adelphia.net send an email to user@greenmountainhealth.com which is an alias on my server that forwards to user@surfglobal.net SurfGlobal will bounce the email because it failed Adelphia's SPF. Perfectly legit email - my spf recs are perfect etc. The solution is SRS - otherwise forwarding is dead -Nick John T (Lists) wrote: I think the underlying problem as has been discussed on this list is that an SPF FAIL should not be relied upon as an outright rejection, rather used as part of a weighting system. John T eServices For You "Seek, and ye shall find!" -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 11:40 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] spf breaks email forwarding - Email customers that forward through me are getting their email bounced because of the original sending domain's spf policy. I understand this delima is addressed with "Sender Rewriting Scheme" http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude Imail? Thanks -Nick --- 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. --- 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.
Re: [Declude.JunkMail] spf breaks email forwarding -
Real-world issues include working around bad implementation, such as surfglobal.net not configuring their server to reject messages that fail SPF. SPF has many real-world issues. SRS is novel, but it is impractical since no one supports it (that I am aware of), and it certainly won't be globally available any time soon. I suggest you tell your customer that they can't forward their E-mail reliably unless surfglobal.net removes their SPF restrictions, and there is nothing that you can do about it. SPF is not a magic bullet. Matt Nick Hayer wrote: The problem is not anything I am doing - it with SPF itself. By design forwarded email will bounce if the receiving MTA is configed that way. Even if I whitelist the emails they will bounce... Let me explain - user@Adelphia.net send an email to user@greenmountainhealth.com which is an alias on my server that forwards to user@surfglobal.net SurfGlobal will bounce the email because it failed Adelphia's SPF. Perfectly legit email - my spf recs are perfect etc. The solution is SRS - otherwise forwarding is dead -Nick John T (Lists) wrote: I think the underlying problem as has been discussed on this list is that an SPF FAIL should not be relied upon as an outright rejection, rather used as part of a weighting system. John T eServices For You "Seek, and ye shall find!" -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 11:40 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] spf breaks email forwarding - Email customers that forward through me are getting their email bounced because of the original sending domain's spf policy. I understand this delima is addressed with "Sender Rewriting Scheme" http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude Imail? Thanks -Nick --- 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. --- 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.
RE: [Declude.JunkMail] spf breaks email forwarding -
Nick, What I've done, and I can't be sure its working, is to set up my client's SPF records like this: v=spf1 ip4:[my ip mx range] ip4:[client ip mx range] mx ~all The range format is nnn.nnn.nnn.nnn/nn I haven't had complaints about SPF rejects. George -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 2:40 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] spf breaks email forwarding - Email customers that forward through me are getting their email bounced because of the original sending domain's spf policy. I understand this delima is addressed with Sender Rewriting Scheme http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude Imail? Thanks -Nick --- 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. --- 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.
RE: [Declude.JunkMail] spf breaks email forwarding -
Nick, Sorry about my last email. I thought you were referring to outbound forwarding, not inbound. George -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 3:27 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] spf breaks email forwarding - The problem is not anything I am doing - it with SPF itself. By design forwarded email will bounce if the receiving MTA is configed that way. Even if I whitelist the emails they will bounce... Let me explain - user@Adelphia.net send an email to user@greenmountainhealth.com which is an alias on my server that forwards to user@surfglobal.net SurfGlobal will bounce the email because it failed Adelphia's SPF. Perfectly legit email - my spf recs are perfect etc. The solution is SRS - otherwise forwarding is dead -Nick John T (Lists) wrote: I think the underlying problem as has been discussed on this list is that an SPF FAIL should not be relied upon as an outright rejection, rather used as part of a weighting system. John T eServices For You Seek, and ye shall find! -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 11:40 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] spf breaks email forwarding - Email customers that forward through me are getting their email bounced because of the original sending domain's spf policy. I understand this delima is addressed with Sender Rewriting Scheme http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude Imail? Thanks -Nick --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type http://www.openspf.org/srs.htmlDoesanyonehaveasolutiontothisw/DecludeIma il?Thanks-Nick---ThisE- mailcamefromtheDeclude.JunkMailmailinglist.Tounsubscribe,justsendanE- [EMAIL PROTECTED],andtype unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.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. --- 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.
Re: [Declude.JunkMail] spf breaks email forwarding -
Matt wrote: Real-world issues include working around bad implementation, such as surfglobal.net not configuring their server to reject messages that fail SPF. SRS is a work around - and I'm simply asking if anyone has implemented it on an Imail/Declude platform. Kindly stay on topic I am aware of your feelings about SPF - all I'm doing is working out a solution with what is in place - an MTA bouncing my legit email. I suggest you tell your customer that they can't forward their E-mail reliably unless surfglobal.net removes their SPF restrictions, and there is nothing that you can do about it. Should I stamp my feet and make a face when I tell them that? :) I can simply ask SurfGlobal to accept me as a trusted sender - but I am trying to avoid that via SRS - so I will not have to make that call or any others. -Nick
RE: [Declude.JunkMail] spf breaks email forwarding -
I was not referring to anything you are doing, I was referring to the recipient domain doing a rejection based upon a SPF fail. John T eServices For You Seek, and ye shall find! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 12:27 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] spf breaks email forwarding - The problem is not anything I am doing - it with SPF itself. By design forwarded email will bounce if the receiving MTA is configed that way. Even if I whitelist the emails they will bounce... Let me explain - user@Adelphia.net send an email to user@greenmountainhealth.com which is an alias on my server that forwards to user@surfglobal.net SurfGlobal will bounce the email because it failed Adelphia's SPF. Perfectly legit email - my spf recs are perfect etc. The solution is SRS - otherwise forwarding is dead -Nick John T (Lists) wrote: I think the underlying problem as has been discussed on this list is that anSPF FAIL should not be relied upon as an outright rejection, rather used aspart of a weighting system.John TeServices For YouSeek, and ye shall find! -Original Message-From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-[EMAIL PROTECTED]] On Behalf Of Nick HayerSent: Saturday, March 04, 2006 11:40 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] spf breaks email forwarding -Email customers that forward through me are getting their email bouncedbecause of the original sending domain's spf policy. I understand thisdelima is addressed with Sender Rewriting Schemehttp://www.openspf.org/srs.htmlDoes anyone have a solution to this w/Declude Imail?Thanks-Nick---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype unsubscribe Declude.JunkMail. The archives can be foundat http://www.mail-archive.com. ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype unsubscribe Declude.JunkMail. The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] spf breaks email forwarding -
Someone could write a plug-in or Declude could be modified to handle this, or IMail could be modified to handle this (and then Declude would probably need to be updated to handle what IMail changed). Why implement a work around in a standards compliant platform in order to deal with a flawed mechanism in use at another provider, when that mechanism is rare? I would prefer that SPF just disappeared. You will probably spend less time telling your client that their destination server has issues that you can't fix and that they should take it up with them. It is not your, my, nor anyone else's responsibility to implement SRS in the current framework. SRS isn't a an RFC standard, in fact according to that page that you provided, it seems that they are moving towards the "SUBMITTER" parameter. Maybe people should have thought about these issues before rushing to support SPF in the first place? SPF, in it's current form, will die. Just give it time. The more support that you give for it, the more resistance to change will exist.and the longer it will take for it to die. The implementation of SPF was always severely flawed, and two years later, there has been hardly any progress at fixing those issues, and there are now several competing sender validation mechanisms, all of which are flawed in one way or another. The technology is all ridiculously short-sighted. It's a problem and not a solution. Matt Nick Hayer wrote: Matt wrote: Real-world issues include working around bad implementation, such as surfglobal.net not configuring their server to reject messages that fail SPF. SRS is a work around - and I'm simply asking if anyone has implemented it on an Imail/Declude platform. Kindly stay on topic I am aware of your feelings about SPF - all I'm doing is working out a solution with what is in place - an MTA bouncing my legit email. I suggest you tell your customer that they can't forward their E-mail reliably unless surfglobal.net removes their SPF restrictions, and there is nothing that you can do about it. Should I stamp my feet and make a face when I tell them that? :) I can simply ask SurfGlobal to accept me as a trusted sender - but I am trying to avoid that via SRS - so I will not have to make that call or any others. -Nick
RE: [Declude.JunkMail] spf breaks email forwarding -
Hear hear. -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matt Sent: Saturday, March 04, 2006 4:36 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] spf breaks email forwarding - Someone could write a plug-in or Declude could be modified to handle this, or IMail could be modified to handle this (and then Declude would probably need to be updated to handle what IMail changed). Why implement a work around in a standards compliant platform in order to deal with a flawed mechanism in use at another provider, when that mechanism is rare? I would prefer that SPF just disappeared. You will probably spend less time telling your client that their destination server has issues that you can't fix and that they should take it up with them. It is not your, my, nor anyone else's responsibility to implement SRS in the current framework. SRS isn't a an RFC standard, in fact according to that page that you provided, it seems that they are moving towards the SUBMITTER parameter. Maybe people should have thought about these issues before rushing to support SPF in the first place? SPF, in it's current form, will die. Just give it time. The more support that you give for it, the more resistance to change will exist.and the longer it will take for it to die. The implementation of SPF was always severely flawed, and two years later, there has been hardly any progress at fixing those issues, and there are now several competing sender validation mechanisms, all of which are flawed in one way or another. The technology is all ridiculously short-sighted. It's a problem and not a solution. Matt Nick Hayer wrote: Matt wrote: Real-world issues include working around bad implementation, such as surfglobal.net not configuring their server to reject messages that fail SPF. SRS is a work around - and I'm simply asking if anyone has implemented it on an Imail/Declude platform. Kindly stay on topic I am aware of your feelings about SPF - all I'm doing is working out a solution with what is in place - an MTA bouncing my legit email. I suggest you tell your customer that they can't forward their E-mail reliably unless surfglobal.net removes their SPF restrictions, and there is nothing that you can do about it. Should I stamp my feet and make a face when I tell them that? :) I can simply ask SurfGlobal to accept me as a trusted sender - but I am trying to avoid that via SRS - so I will not have to make that call or any others. -Nick --- 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.
[Declude.JunkMail] SPF PASS/FAIL test format
Quick question on the global.cfg file I upgraded to 3.0.5 yesterday. Working great so far. I want to add the SPFPASS and SPFFAIL tests.. what is the format ? I want to subtract 7 points for a pass, and add 7 points for a fail( if theyre too stupid to have an SPF by now ) I have this, but it is obviously wrong SPFFAIL spffail x x 7 0 SPFPASS spfpass x x -7 0 Karl Drugge B.S.I.T., A.S., M.C.S.E. ( NT 4.0 + 2000 ), C.C.N.A., C.C.D.A., Network+, A+ I dream of the day when I will learn to stop asking questions to which I will regret learning the answers ( Roy Greenhilt, Order of the Stick ) PLEASE NOTE : Florida has a very broad public records law. Most written communications to or from City officials regarding City business are public records available to the public and media upon request. Your E-mail communications may be subject to public disclosure.
RE: [Declude.JunkMail] SPF PASS/FAIL test format
Karl, the correct format is as below: SPFPASSspfpassx00SPFFAILspffailx50 Note that nobody usesSPFPASS to grant a negative weight to an incoming message. This is because a certain family of the bad guysdefinitely use SPF and their own mail servers, and we don't want to help them. The best practice is to score a positive weight for a hit on SPFFAIL, ignore SPFUNKNOWN, and not grant a negative weight on SPFPASS. If you want to go the extra mile, use SPFPASS asa test in a JunkMail Pro filter file in combination with other tests. Idea 1) Use it with TESTSFAILED to stop processing early ina filter file that checks for zombie spam to mitigate false positives. Idea 2) Use it with a filter file that already awards negative points to your important business partners to award extra negative weight so as to mitigate false positives (e.g. to counterbalance a sudden listing of their IP address in SpamCop). Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IS - Systems Eng. (Karl Drugge)Sent: Thursday, December 08, 2005 10:09 AMTo: declude.junkmail@declude.comSubject: [Declude.JunkMail] SPF PASS/FAIL test format Quick question on the global.cfg file I upgraded to 3.0.5 yesterday. Working great so far. I want to add the SPFPASS and SPFFAIL tests.. what is the format ? I want to subtract 7 points for a pass, and add 7 points for a fail( if theyre too stupid to have an SPF by now ) I have this, but it is obviously wrong SPFFAIL spffail x x 7 0 SPFPASS spfpass x x -7 0 Karl Drugge B.S.I.T., A.S., M.C.S.E. ( NT 4.0 + 2000 ), C.C.N.A., C.C.D.A., Network+, A+ I dream of the day when I will learn to stop asking questions to which I will regret learning the answers ( Roy Greenhilt, Order of the Stick ) PLEASE NOTE : Florida has a very broad public records law. Most written communications to or from City officials regarding City business are public records available to the public and media upon request. Your E-mail communications may be subject to public disclosure.
Re: [Declude.JunkMail] SPF PASS/FAIL test format
Also make sure you have at least version 3.0.5.20 Previous 3.0.5. versions had an error with SPF Original Message - From: IS - Systems Eng. (Karl Drugge) To: declude.junkmail@declude.com Sent: Thursday, December 08, 2005 12:08 PM Subject: [Declude.JunkMail] SPF PASS/FAIL test format Quick question on the global.cfg file I upgraded to 3.0.5 yesterday. Working great so far. I want to add the SPFPASS and SPFFAIL tests.. what is the format ? I want to subtract 7 points for a pass, and add 7 points for a fail ( if theyre too stupid to have an SPF by now ) I have this, but it is obviously wrong SPFFAIL spffail x x 7 0 SPFPASS spfpass x x -7 0 Karl Drugge B.S.I.T., A.S., M.C.S.E. ( NT 4.0 + 2000 ), C.C.N.A., C.C.D.A., Network+, A+ I dream of the day when I will learn to stop asking questions to which I will regret learning the answers ( Roy Greenhilt, Order of the Stick ) PLEASE NOTE : Florida has a very broad public records law. Most written communications to or from City officials regarding City business are public records available to the public and media upon request. Your E-mail communications may be subject to public disclosure.
RE: [Declude.JunkMail] SPF PASS/FAIL test format
Which may still be there. I reported a false positive to declude the other day. Where declude sais the email failed but running the check from dnsstuff.com it passes. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Scott FisherSent: Thursday, December 08, 2005 10:55 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] SPF PASS/FAIL test format Also make sure you have at least version 3.0.5.20 Previous 3.0.5. versions had an error with SPF Original Message - From: IS - Systems Eng. (Karl Drugge) To: declude.junkmail@declude.com Sent: Thursday, December 08, 2005 12:08 PM Subject: [Declude.JunkMail] SPF PASS/FAIL test format Quick question on the global.cfg file I upgraded to 3.0.5 yesterday. Working great so far. I want to add the SPFPASS and SPFFAIL tests.. what is the format ? I want to subtract 7 points for a pass, and add 7 points for a fail ( if theyre too stupid to have an SPF by now ) I have this, but it is obviously wrong SPFFAIL spffail x x 7 0 SPFPASS spfpass x x -7 0 Karl Drugge B.S.I.T., A.S., M.C.S.E. ( NT 4.0 + 2000 ), C.C.N.A., C.C.D.A., Network+, A+ I dream of the day when I will learn to stop asking questions to which I will regret learning the answers ( Roy Greenhilt, Order of the Stick ) PLEASE NOTE : Florida has a very broad public records law. Most written communications to or from City officials regarding City business are public records available to the public and media upon request. Your E-mail communications may be subject to public disclosure.
RE: [Declude.JunkMail] SPF PASS/FAIL test format
I have quick question re. 3.0 version of Declude. I installed both the .20 and the .21 version on a windows 2003 enterprise server with Imail 8.15 hf2 and discovered a memory leak. I've not heard back from Declude as to a fix. I'd like to go to 8.22 to address a few issues but am worried about 3.0.5.21 having the memory leak. I can only run about 2 to 4 hours before we seem to lose the ability to access dns. and run low on memory. Does 8.22 require 3.0 or can I run my 2.x version? Does anyone have any experiance with this and would share any thoughts. thanks John -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Scott FisherSent: Thursday, December 08, 2005 10:55 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] SPF PASS/FAIL test format Also make sure you have at least version 3.0.5.20 Previous 3.0.5. versions had an error with SPF Original Message - From: IS - Systems Eng. (Karl Drugge) To: declude.junkmail@declude.com Sent: Thursday, December 08, 2005 12:08 PM Subject: [Declude.JunkMail] SPF PASS/FAIL test format Quick question on the global.cfg file I upgraded to 3.0.5 yesterday. Working great so far. I want to add the SPFPASS and SPFFAIL tests.. what is the format ? I want to subtract 7 points for a pass, and add 7 points for a fail ( if theyre too stupid to have an SPF by now ) I have this, but it is obviously wrong SPFFAIL spffail x x 7 0 SPFPASS spfpass x x -7 0 Karl Drugge B.S.I.T., A.S., M.C.S.E. ( NT 4.0 + 2000 ), C.C.N.A., C.C.D.A., Network+, A+ I dream of the day when I will learn to stop asking questions to which I will regret learning the answers ( Roy Greenhilt, Order of the Stick ) PLEASE NOTE : Florida has a very broad public records law. Most written communications to or from City officials regarding City business are public records available to the public and media upon request. Your E-mail communications may be subject to public disclosure.
RE: [Declude.JunkMail] SPF PASS/FAIL test format
Does 8.22 require 3.0 or can I run my 2.x version? Imail 8.20+ requires Declude 3.0 or later. David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John DoyleSent: Thursday, December 08, 2005 2:16 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] SPF PASS/FAIL test format I have quick question re. 3.0 version of Declude. I installed both the .20 and the .21 version on a windows 2003 enterprise server with Imail 8.15 hf2 and discovered a memory leak. I've not heard back from Declude as to a fix. I'd like to go to 8.22 to address a few issues but am worried about 3.0.5.21 having the memory leak. I can only run about 2 to 4 hours before we seem to lose the ability to access dns. and run low on memory. Does 8.22 require 3.0 or can I run my 2.x version? Does anyone have any experiance with this and would share any thoughts. thanks John -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Scott FisherSent: Thursday, December 08, 2005 10:55 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] SPF PASS/FAIL test format Also make sure you have at least version 3.0.5.20 Previous 3.0.5. versions had an error with SPF Original Message - From: IS - Systems Eng. (Karl Drugge) To: declude.junkmail@declude.com Sent: Thursday, December 08, 2005 12:08 PM Subject: [Declude.JunkMail] SPF PASS/FAIL test format Quick question on the global.cfg file I upgraded to 3.0.5 yesterday. Working great so far. I want to add the SPFPASS and SPFFAIL tests.. what is the format ? I want to subtract 7 points for a pass, and add 7 points for a fail( if theyre too stupid to have an SPF by now ) I have this, but it is obviously wrong SPFFAIL spffail x x 7 0 SPFPASS spfpass x x -7 0 Karl Drugge B.S.I.T., A.S., M.C.S.E. ( NT 4.0 + 2000 ), C.C.N.A., C.C.D.A., Network+, A+ I dream of the day when I will learn to stop asking questions to which I will regret learning the answers ( Roy Greenhilt, Order of the Stick ) PLEASE NOTE : Florida has a very broad public records law. Most written communications to or from City officials regarding City business are public records available to the public and media upon request. Your E-mail communications may be subject to public disclosure.
Re: [Declude.JunkMail] SPF PASS/FAIL test format
Karl, The correct format is SPFFAIL spf fail x 7 0 DarrellinvURIBL - Intelligent URI filtering plug-in for Declude, mxGuard, and ORF. Stop spam at the source the spamvertised domain. More effective than traditional RBL's. Try it today - http://www.invariantsystems.com - Original Message - From: IS - Systems Eng. (Karl Drugge) To: declude.junkmail@declude.com Sent: Thursday, December 08, 2005 1:08 PM Subject: [Declude.JunkMail] SPF PASS/FAIL test format Quick question on the global.cfg file I upgraded to 3.0.5 yesterday. Working great so far. I want to add the SPFPASS and SPFFAIL tests.. what is the format ? I want to subtract 7 points for a pass, and add 7 points for a fail ( if theyre too stupid to have an SPF by now ) I have this, but it is obviously wrong SPFFAIL spffail x x 7 0 SPFPASS spfpass x x -7 0 Karl Drugge B.S.I.T., A.S., M.C.S.E. ( NT 4.0 + 2000 ), C.C.N.A., C.C.D.A., Network+, A+ I dream of the day when I will learn to stop asking questions to which I will regret learning the answers ( Roy Greenhilt, Order of the Stick ) PLEASE NOTE : Florida has a very broad public records law. Most written communications to or from City officials regarding City business are public records available to the public and media upon request. Your E-mail communications may be subject to public disclosure.
RE: [Declude.JunkMail] SPF - Missing the Point
still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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.
RE: [Declude.JunkMail] SPF - Missing the Point
That's right on the money, Andy. I agree 100%. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Thursday, September 08, 2005 8:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SPF - Missing the Point still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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. --- 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.
Re: [Declude.JunkMail] SPF - Missing the Point
Excellent point, Andy. Not just detecting spoofing, but changing behavior to avoid future spoofing. Darin. - Original Message - From: Andy Schmidt [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:47 AM Subject: RE: [Declude.JunkMail] SPF - Missing the Point still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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. --- 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.
RE: [Declude.JunkMail] SPF - Missing the Point
On 11:47 AM 9/8/2005 -0400, it would appear that Andy Schmidt wrote: still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude.. [snip] If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name. No, the effect is that if I define SPF (which I don't and won't as I'll explain) then I am forced to either write includes for Netzero, Xmission, Connect2 and every other ISP that my users (employees) use at home where they also write emails that legitimately use @cvwrf.org. If I use SPF and *don't* write those includes then I am forcing a FAIL when those users send mail through their home ISP using @cvwrf.org. If, however, I don't have any SPF record (which I don't) then at worst an SPF test is required to return a NONE/NEUTRAL. Some ISPs do reject on FAIL but I have yet to find one that rejects on a NONE/NEUTRAL because the RFC specifies that NONE/NEUTRAL should not be rejected out of hand. For example, SPFFAIL is *not* triggered if a domain has no SPF record. From the Junkmail manual: Note that it will not be triggered for E-mail that has other problems (no SPF record, unknown results from the SPF record, etc.). So any E-mail failing the SPFFAIL test is E-mail that is not authorized per the administrator of the domain the E-mail is being sent from. In short, I better ensure my that my users can send mail regardless of their location by not having any SPF record. That also means that I do no SPF checks on incoming mail, in my view it is simply too unreliable. Besides, my other Declude tests are already catching 97% of the SPAM we receive with only 0.03% of those messages caught being false positives. As to using port 587 as you suggested early Andy, we may do that eventually but currently 587 usage is still not widespread enough on the client side. Sure, I can *make* 587 work for nearly any client out there but that will break port 25 usage on many of those clients. Example: Any Eudora client older than 17 June 2005 can use *either* port 25 or port 587 for sending. Besides, I *really* don't want to make 73 house calls to get my users over to port 587. ;) Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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.
Re: [Declude.JunkMail] SPF - Missing the Point
Well, it's entirely up to you: Tell your users to send out through your server instead of their ISP(over port 587 if the ISP is blocking 25) or use the SPF neutral response instead of pass or fail. Yes, it requires a little work, but for us it has proven useful. I don't think anyone is saying it's perfect, but it can be implemented in a useful fashion. Darin. - Original Message - From: Tyran Ormond [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 12:39 PM Subject: RE: [Declude.JunkMail] SPF - Missing the Point On 11:47 AM 9/8/2005 -0400, it would appear that Andy Schmidt wrote: still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude.. [snip] If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name. No, the effect is that if I define SPF (which I don't and won't as I'll explain) then I am forced to either write includes for Netzero, Xmission, Connect2 and every other ISP that my users (employees) use at home where they also write emails that legitimately use @cvwrf.org. If I use SPF and *don't* write those includes then I am forcing a FAIL when those users send mail through their home ISP using @cvwrf.org. If, however, I don't have any SPF record (which I don't) then at worst an SPF test is required to return a NONE/NEUTRAL. Some ISPs do reject on FAIL but I have yet to find one that rejects on a NONE/NEUTRAL because the RFC specifies that NONE/NEUTRAL should not be rejected out of hand. For example, SPFFAIL is *not* triggered if a domain has no SPF record. From the Junkmail manual: Note that it will not be triggered for E-mail that has other problems (no SPF record, unknown results from the SPF record, etc.). So any E-mail failing the SPFFAIL test is E-mail that is not authorized per the administrator of the domain the E-mail is being sent from. In short, I better ensure my that my users can send mail regardless of their location by not having any SPF record. That also means that I do no SPF checks on incoming mail, in my view it is simply too unreliable. Besides, my other Declude tests are already catching 97% of the SPAM we receive with only 0.03% of those messages caught being false positives. As to using port 587 as you suggested early Andy, we may do that eventually but currently 587 usage is still not widespread enough on the client side. Sure, I can *make* 587 work for nearly any client out there but that will break port 25 usage on many of those clients. Example: Any Eudora client older than 17 June 2005 can use *either* port 25 or port 587 for sending. Besides, I *really* don't want to make 73 house calls to get my users over to port 587. ;) Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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. --- 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.
Re: [Declude.JunkMail] SPF - Missing the Point
But isn't this utopian? The majority of situations have exceptions as they apply to SPF, and in a world where there are open relays on every corner, many servers without proper reverse DNS records, etc., would you really want to trust others to maintain SPF records accurately? I use a custom filter for tagging local domains in incoming E-mail. Since all of my customers' servers are whitelisted, and hosted clients are also whitelisted through AUTH, I can add a couple of points for anything with a Mail From that matches something that I handle. This does have false positives, many in fact due to mailers that forge such as greeting cards or feedback forms, devices that send out notifications with their own SMTP engine, people that are port 25 blocked or proxied, configured to use their own ISP's SMTP server, Web applications, etc. SPF isn't required to do this. I don't trust how well some random admin manages their own SPF records, and if I had my own SPF records, I wouldn't trust how some random admin treated a failure among my own customers. At least they aren't going to be tagged for sending E-mail from someplace that they didn't know not to send from, and is otherwise perfectly acceptable. I am obviously not going to give any credit to anyone for passing SPF either. Passing SPF is a better indication of spam than of legitimate E-mail these days for incoming traffic. I have never been a big fan of SPF because of what I saw as an impractical and unreliable implementation in the real world. It really isn't any better than Habeas once you get down to it, but people ate that up for a while as well. We have many tools available to us these days that are quite effective and much more accurate. Forging spam almost never leaks through my system, and it's not something that I care to focus on at all these days. It's things like Advance Fee Fraud, Phishing, Niche Spam, and First Run Static Spam that concern me. Matt Colbeck, Andrew wrote: That's right on the money, Andy. I agree 100%. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt Sent: Thursday, September 08, 2005 8:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SPF - Missing the Point still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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. --- 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.
RE: [Declude.JunkMail] SPF - Missing the Point
Hi Matt: I read your posting (because you are always insightful), but I'm not sure that your message actually applies to what I had said(and to which Andrew had commented on) or if youmay beanswering to a different part of the conversation. Certainly nothing Utopian in what I wrote? a) It isplain fact that the largest providers do check SPF, which in turn means that Joe-Jobs have a drastically lower impact on the spoofed domain's owner. b) It is also a fact, that spammers are very SPF aware (to the point that they create SPF records.) c) Based on my personal, admittedly anecdotal, experience (supported bycommon sense) it further appears to me that SPF protected domainswould beless likely to get picked for Joe-Jobs than unprotected domains. Here is what I had written: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names?If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place.The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Thursday, September 08, 2005 01:55 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] SPF - Missing the Point But isn't this utopian? The majority of situations have exceptions as they apply to SPF, and in a world where there are open relays on every corner, many servers without proper reverse DNS records, etc., would you really want to trust others to maintain SPF records accurately?I use a custom filter for tagging local domains in incoming E-mail. Since all of my customers' servers are whitelisted, and hosted clients are also whitelisted through AUTH, I can add a couple of points for anything with a Mail From that matches something that I handle. This does have false positives, many in fact due to mailers that forge such as greeting cards or feedback forms, devices that send out notifications with their own SMTP engine, people that are port 25 blocked or proxied, configured to use their own ISP's SMTP server, Web applications, etc. SPF isn't required to do this. I don't trust how well some random admin manages their own SPF records, and if I had my own SPF records, I wouldn't trust how some random admin treated a failure among my own customers. At least they aren't going to be tagged for sending E-mail from someplace that they didn't know not to send from, and is otherwise perfectly acceptable. I am obviously not going to give any credit to anyone for passing SPF either. Passing SPF is a better indication of spam than of legitimate E-mail these days for incoming traffic.I have never been a big fan of SPF because of what I saw as an impractical and unreliable implementation in the real world. It really isn't any better than Habeas once you get down to it, but people ate that up for a while as well. We have many tools available to us these days that are quite effective and much more accurate. Forging spam almost never leaks through my system, and it's not something that I care to focus on at all these days. It's things like Advance Fee Fraud, Phishing, Niche Spam, and First Run Static Spam that concern me.MattColbeck, Andrew wrote: That's right on the money, Andy. I agree 100%. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt Sent: Thursday, September 08, 2005 8:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SPF - Missing the Point still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined
Re: [Declude.JunkMail] SPF - Missing the Point
reliably in real world circumstances, and it can create more issues than it solves on even properly administrated systems. It totally fails at it's original primary goal of authenticating good E-mail. All of these issues should have been obvious since the very beginning. IMO, this effort should have gone into pushing port 587 functionality and adoption in not just mail servers, but also in mail clients as a default config so that we could move towards blocking port 25 on broadband connections without affecting legitimate use. This would cut down on not just spam, but also the viruses that opened the computers in the first place. Resistance to blocking port 25 is totally a consequence of not having a legitimate alternative. Matt Andy Schmidt wrote: Hi Matt: I read your posting (because you are always insightful), but I'm not sure that your message actually applies to what I had said(and to which Andrew had commented on) or if youmay beanswering to a different part of the conversation. Certainly nothing Utopian in what I wrote? a) It isplain fact that the largest providers do check SPF, which in turn means that Joe-Jobs have a drastically lower impact on the spoofed domain's owner. b) It is also a fact, that spammers are very SPF aware (to the point that they create SPF records.) c) Based on my personal, admittedly anecdotal, experience (supported bycommon sense) it further appears to me that SPF protected domainswould beless likely to get picked for Joe-Jobs than unprotected domains. Here is what I had written: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: Thursday, September 08, 2005 01:55 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF - Missing the Point But isn't this utopian? The majority of situations have exceptions as they apply to SPF, and in a world where there are open relays on every corner, many servers without proper reverse DNS records, etc., would you really want to trust others to maintain SPF records accurately? I use a custom filter for tagging local domains in incoming E-mail. Since all of my customers' servers are whitelisted, and hosted clients are also whitelisted through AUTH, I can add a couple of points for anything with a Mail From that matches something that I handle. This does have false positives, many in fact due to mailers that forge such as greeting cards or feedback forms, devices that send out notifications with their own SMTP engine, people that are port 25 blocked or proxied, configured to use their own ISP's SMTP server, Web applications, etc. SPF isn't required to do this. I don't trust how well some random admin manages their own SPF records, and if I had my own SPF records, I wouldn't trust how some random admin treated a failure among my own customers. At least they aren't going to be tagged for sending E-mail from someplace that they didn't know not to send from, and is otherwise perfectly acceptable. I am obviously not going to give any credit to anyone for passing SPF either. Passing SPF is a better indication of spam than of legitimate E-mail these days for incoming traffic. I have never been a big fan of SPF because of what I saw as an impractical and unreliable implementation in the real world. It really isn't any better than Habeas once you get down to it, but people ate that up for a while as well. We have many tools available to us these days that are quite effective and much more accurate. Forging spam almost never leaks through my system, and it's not something that I care to focus on at all these days. It's things like Advance Fee Fraud, Phishing, Niche Spam, and First Run Static Spam that concern me. Matt Colbeck, Andrew wrote: That's right on the money, Andy. I agree 100%. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt Sent: Thursday, September 08, 2005 8:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SPF - Missing the Point
Re: [Declude.JunkMail] SPF logs
Just noticed that the SPF logs that were stored in C:\ are gone. Did they get moved or where they done away with? They were done away with. They were part of the beta testing of SPF. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. This outgoing message is guaranteed to be authentic by Message Level users. Guarantee the authenticity of your email @ http://www.messagelevel.com. --- [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.
Re: [Declude.JunkMail] SPF logs
Repost. - Original Message - From: Darin Cox [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Friday, January 14, 2005 10:59 AM Subject: SPF logs Just noticed that the SPF logs that were stored in C:\ are gone. Did they get moved or where they done away with? Darin. --- [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.
[Declude.JunkMail] SPF logs
Just noticed that the SPF logs that were stored in C:\ are gone. Did they get moved or where they done away with? Darin. --- [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.
[Declude.JunkMail] SPF uptake results in...
Title: Message ... 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 hasa 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) InJanuary 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 MattSent: Sunday, January 09, 2005 7:48 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] BlankSubject v1.0.0 external filterI 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.zipThere 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/ =
Re: [Declude.JunkMail] SPF uptake results in...
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 hasa 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) InJanuary 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
Re[2]: [Declude.JunkMail] SPF uptake results in...
. . . I haven't yet seen whether or not CDO allows for this, and if it doesn't, it predisposes the developer to forge. FYI, CDO (CDOSYS) allows for the requisite separate values. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.mailmage.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.mailmage.com/products/software/freeutils/exchange2aliases/download/release/ http://www.mailmage.com/products/software/freeutils/ldap2aliases/download/release/ --- [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.
RE: [Declude.JunkMail] SPF Success
Matt, In my eyes setting up SPF-records for the own domains is not a defensive action to preventspam but an active. The goal is to let see the spammers: Hey this domain has records allowing valid messages only from IP x.x.x.x According to my reliability measurements SPFPASS is used up to 40% by spammers. So it's not usable to add a negative weight and let bypass valif messages. On the other side spammers can't affect on valid SPF records of my domains. If I can be sure that my customers are sending their messages only trough my server I can set up strong SPF records. So spammers can see this and other spam filters can use the record to block other messages with my mailfrom domains but invalid sender IP's. Even if this will not reduce the number of incomming spam on other servers and my servers to, I hope it will significantly reduce the forged mailfrom's containg my domains. The first positive thing I should can see is a reduced number of NDR's. Then I can only hope that more and more Admin's are going to use SPF records. At a certain level domains without SPF-Records will drown under the load of forged mailfrom adresses and they must set up SPF records as solution. And it should help also against zombies: Theoreticaly it should be possible for Internet access providers to block SPF-TXT requests to their DNS-servers from the own DUL and xDSL-Lines. Now a zombi-computer has big problems to determine what domains he can use for forged mailfroms. Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Friday, December 24, 2004 3:24 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] SPF Success To enter SPF settings in a majority DNS server out there, especially those with control panels, is never going to happen. It is also more technical than most can accomplish (not us for the most of course). This will remain an implementation that is primarily applied to larger domains and otherwise sporadically.If the goal is to determine if someone is forging local addresses, I use a filter that I call FORGEDFROM which is a derivative of SPAMDOMAINS, using a single column file like so: @example.com @example.net @example.org ...I whitelist AUTH, and also gatewayed mail servers, but there are plenty of exceptions where people still use their ISP's mail server, so this filter only gets 20% of my hold weight. It is much easier to implement, especially since I don't have access to most of my customer's DNS servers.I also use SPAMDOMAINS for many larger domains and I fear that false positives would cause double hits on SPF-FALSE and SPAMDOMAINS, so I have chosen not to bother. This might change with time, but I don't expect widespread use.SPF has no promise in it's current format of validating legitimate E-mail since spammers are using it, which seemingly was the primary original goal, and due to mail servers sending E-mail with the Mail From of the client software, there is always going to be a fair number of false positives caused by it's use.For something to be successful in this market, it would have to be built into the mail server and not DNS, otherwise it won't ever become widely popular due to issues with implementing it. With spammers hacking accounts in larger providers, and hosting providers mixing spammers with legitimate customers on the same mail servers, I remain unconvinced that there will a solution that is suitable to the real issue at hand for some time to come. Yeah, I know...bah humbug :)IMO, the best way to stop forging is to stop zombie spammers. The way to do this is FIRST implement port 587 as AUTH-only, and then widely block port 25. This means that mail clients would exclusively use AUTH on private networks and connect to their mail server on port 587 where only AUTHed connections would be allowed. Then only servers would share non-AUTH E-mail on port 25. The only reason why blocking port 25 is not very common currently is because it is severely limiting to customers and would cause support issues for the ISP. If you first did the migration to port 587 AUTH-only connections, which would take several years to accomplish in good order, ISP's could move forward with port 25 blocking and cause many fewer issues as far as support and their clients were concerned.Basically what I am saying is that forging isn't the issue, it's spam zombies, and to go after it as a forging issue is to miss the point. The big caveat here is that spammers will turn to hacking AUTH in much larger numbers, and E-mail server software should also widely implement a 'hijack' detection mechanism in order to help stem the abuse. I have already noted much more hacking going on, first with Earthlink's properties, and now with Prodigy as well. I have little faith that these things will happen in the proper
RE: [Declude.JunkMail] SPF Success
As many Admin's who has the possibility to set up SPF records are ISPs with their own DNS-Servers I just want to note that you should ensure, that each customer is realy sending out mails only trough your MTA. If not you will punish also legit messages. The problem is: How to know if the messages processed on you MTA are the only ones? Ok, if there are relayed messages from one customer to a remote MTA we can expect the customer is not using a local SMTP-Server who does MX lookups and direct delivery. But what about customerside applications (for example CRM) who does exactly that? The solution of setting up soft SPF records will not more prevent you anymore from being forged... Markus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox Sent: Friday, December 24, 2004 3:01 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF Success Middling success, but definitely beneficial...the biggest benefit we've seen is in blocking forged spam from domains we serve. By implementing SPF for those domains, we can fail email that doesn't come from our servers. So, forging spam that uses the destination address as the from address is easily caught. Darin. - Original Message - From: Danny [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Thursday, December 23, 2004 8:48 PM Subject: [Declude.JunkMail] SPF Success I'm setting up SPF. Just wondering what success SPF has had with marking spam for anyone? --- [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. --- [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. --- [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.
Re: [Declude.JunkMail] SPF Success
Certainly. We have a few customers that use other mail servers, so for those we set the basic SPF record that says we don't know where they will send from. However, most customers are not savvy enough to change their mail servers, so when we tell them our mail server address that's all they will use. One other point about SPF records. If you have domains that do not send mail, drop an SPF record in that says they don't send mail at all. We've had some success with that as well...especially if it's a domain that was previously active but now just being held onto... like with a company name change where you still want the website traffic, but no email from it anymore. Darin. - Original Message - From: Markus Gufler [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Friday, December 24, 2004 4:34 AM Subject: RE: [Declude.JunkMail] SPF Success As many Admin's who has the possibility to set up SPF records are ISPs with their own DNS-Servers I just want to note that you should ensure, that each customer is realy sending out mails only trough your MTA. If not you will punish also legit messages. The problem is: How to know if the messages processed on you MTA are the only ones? Ok, if there are relayed messages from one customer to a remote MTA we can expect the customer is not using a local SMTP-Server who does MX lookups and direct delivery. But what about customerside applications (for example CRM) who does exactly that? The solution of setting up soft SPF records will not more prevent you anymore from being forged... Markus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox Sent: Friday, December 24, 2004 3:01 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF Success Middling success, but definitely beneficial...the biggest benefit we've seen is in blocking forged spam from domains we serve. By implementing SPF for those domains, we can fail email that doesn't come from our servers. So, forging spam that uses the destination address as the from address is easily caught. Darin. - Original Message - From: Danny [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Thursday, December 23, 2004 8:48 PM Subject: [Declude.JunkMail] SPF Success I'm setting up SPF. Just wondering what success SPF has had with marking spam for anyone? --- [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. --- [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. --- [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. --- [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.
Re: [Declude.JunkMail] SPF Success
One other thing I left out... As SPF becomes more widespread and ISPs implement it, SPF record inheritance will become a viable solution to the customer using ISP mail servers dilemma. That is, if the ISP sets SPF records that define what their mail servers are, then we can reference their SPF records in the SPF records we set up for a domain. So, by specifying to inherit the customer's ISPs records, we tell SPF that email from the domain can come from our mail servers or the ISPs mail servers without having to know and specify all of the ISPs mail servers. Darin. - Original Message - From: Darin Cox [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Friday, December 24, 2004 7:14 AM Subject: Re: [Declude.JunkMail] SPF Success Certainly. We have a few customers that use other mail servers, so for those we set the basic SPF record that says we don't know where they will send from. However, most customers are not savvy enough to change their mail servers, so when we tell them our mail server address that's all they will use. One other point about SPF records. If you have domains that do not send mail, drop an SPF record in that says they don't send mail at all. We've had some success with that as well...especially if it's a domain that was previously active but now just being held onto... like with a company name change where you still want the website traffic, but no email from it anymore. Darin. - Original Message - From: Markus Gufler [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Friday, December 24, 2004 4:34 AM Subject: RE: [Declude.JunkMail] SPF Success As many Admin's who has the possibility to set up SPF records are ISPs with their own DNS-Servers I just want to note that you should ensure, that each customer is realy sending out mails only trough your MTA. If not you will punish also legit messages. The problem is: How to know if the messages processed on you MTA are the only ones? Ok, if there are relayed messages from one customer to a remote MTA we can expect the customer is not using a local SMTP-Server who does MX lookups and direct delivery. But what about customerside applications (for example CRM) who does exactly that? The solution of setting up soft SPF records will not more prevent you anymore from being forged... Markus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox Sent: Friday, December 24, 2004 3:01 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF Success Middling success, but definitely beneficial...the biggest benefit we've seen is in blocking forged spam from domains we serve. By implementing SPF for those domains, we can fail email that doesn't come from our servers. So, forging spam that uses the destination address as the from address is easily caught. Darin. - Original Message - From: Danny [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Thursday, December 23, 2004 8:48 PM Subject: [Declude.JunkMail] SPF Success I'm setting up SPF. Just wondering what success SPF has had with marking spam for anyone? --- [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. --- [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. --- [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. --- [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. --- [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.
Re: [Declude.JunkMail] SPF Success
To enter SPF settings in a majority DNS server out there, especially those with control panels, is never going to happen. It is also more technical than most can accomplish (not us for the most of course). This will remain an implementation that is primarily applied to larger domains and otherwise sporadically. If the goal is to determine if someone is forging local addresses, I use a filter that I call FORGEDFROM which is a derivative of SPAMDOMAINS, using a single column file like so: @example.com @example.net @example.org ... I whitelist AUTH, and also gatewayed mail servers, but there are plenty of exceptions where people still use their ISP's mail server, so this filter only gets 20% of my hold weight. It is much easier to implement, especially since I don't have access to most of my customer's DNS servers. I also use SPAMDOMAINS for many larger domains and I fear that false positives would cause double hits on SPF-FALSE and SPAMDOMAINS, so I have chosen not to bother. This might change with time, but I don't expect widespread use. SPF has no promise in it's current format of validating legitimate E-mail since spammers are using it, which seemingly was the primary original goal, and due to mail servers sending E-mail with the Mail >From of the client software, there is always going to be a fair number of false positives caused by it's use. For something to be successful in this market, it would have to be built into the mail server and not DNS, otherwise it won't ever become widely popular due to issues with implementing it. With spammers hacking accounts in larger providers, and hosting providers mixing spammers with legitimate customers on the same mail servers, I remain unconvinced that there will a solution that is suitable to the real issue at hand for some time to come. Yeah, I know...bah humbug :) IMO, the best way to stop forging is to stop zombie spammers. The way to do this is FIRST implement port 587 as AUTH-only, and then widely block port 25. This means that mail clients would exclusively use AUTH on private networks and connect to their mail server on port 587 where only AUTHed connections would be allowed. Then only servers would share non-AUTH E-mail on port 25. The only reason why blocking port 25 is not very common currently is because it is severely limiting to customers and would cause support issues for the ISP. If you first did the migration to port 587 AUTH-only connections, which would take several years to accomplish in good order, ISP's could move forward with port 25 blocking and cause many fewer issues as far as support and their clients were concerned. Basically what I am saying is that forging isn't the issue, it's spam zombies, and to go after it as a forging issue is to miss the point. The big caveat here is that spammers will turn to hacking AUTH in much larger numbers, and E-mail server software should also widely implement a 'hijack' detection mechanism in order to help stem the abuse. I have already noted much more hacking going on, first with Earthlink's properties, and now with Prodigy as well. I have little faith that these things will happen in the proper order or with the expedience necessary unfortunately, especially because of what I consider to be a distraction focused on forging coming from the likes of SPF, Microsoft and Yahoo. I feel that the big players are missing the point, and they are the ones that heavily influence E-mail client and server software which is where the changes first need to be implemented. Matt Darin Cox wrote: One other thing I left out... As SPF becomes more widespread and ISPs implement it, SPF record inheritance will become a viable solution to the customer using ISP mail servers dilemma. That is, if the ISP sets SPF records that define what their mail servers are, then we can reference their SPF records in the SPF records we set up for a domain. So, by specifying to "inherit" the customer's ISPs records, we tell SPF that email from the domain can come from our mail servers or the ISPs mail servers without having to know and specify all of the ISPs mail servers. Darin. - Original Message - From: "Darin Cox" [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Friday, December 24, 2004 7:14 AM Subject: Re: [Declude.JunkMail] SPF Success Certainly. We have a few customers that use other mail servers, so for those we set the basic SPF record that says we don't know where they will send from. However, most customers are not savvy enough to change their mail servers, so when we tell them our mail server address that's all they will use. One other point about SPF records. If you have domains that do not send mail, drop an SPF record in that says they don't send mail at all. We've had some success with that as well...especially if it's a domain that was previously active but now just being held onto... like with a company name change where you still want the websit
RE: [Declude.JunkMail] SPF Success
Hi; I have added a couple of filters that work quite well using SPF. Although by itself it does not do much but as a combination it is working for us. Towards the end of the filters I have a couple of combo filters that I called [Elevate.?] where ? is the category of elevate weight. The [Elevate.SPF.Fail] is as follows: SKIPIFWEIGHT 50 TESTSFAILEDEND NOTCONTAINS [SPF.FAIL]TESTSFAILEDENDNOTCONTAINS [COMBO.LINK] TESTSFAILED0CONTAINS[NOLEGITCONTENT]TESTSFAILED0CONTAINS[HEURTESTSFAILED0CONTAINS[REVDNS] - the Combo.Link filter is a set of filters that detects if the email has any image or URL links in the body. Here is the [COMBO.LINK] filter: SKIPIFWEIGHT 50 TESTSFAILED 0 CONTAINS [LINK.BODY] TESTSFAILED 0 CONTAINS [LINK.BODY.IP]TESTSFAILED 0 CONTAINS [EMAIL PROTECTED]TESTSFAILED 0 CONTAINS [LINK.BODY.IMAGE] [ELEVATE.SPF.FAIL]has 100% hit on spam that might have gotten through or not deleted. I have not seen a false positivebut of course it does not mean it won't on other systems. Regards, Kami
RE: [Declude.JunkMail] SPF Success
Title: Message I can contribute a complementary test. In this forum we've harangued over whether SPFPASS is useful and generally agreed thatthe bulk mail companies can use it, yet you don't want their mail. Also, that anybody that implements SPF probably runs their mailserver and DNS configuration such that they won't get held by your Declude JunkMail anyway. Well, for two months I've been running this with good success with JunkMail Pro... I use SPFPASS as a flag. Based on that flag, I then check whether various reliable RBL tests have triggered that would indicate that the message is from a bad guy. Based on SPFPASS being triggered, and none of my RBL tests being triggered, I then give the message some counterweight. This has worked very well, and I've had only one specific false-positive (an ISP that has SPF set to allow their client space to send mail as the ISP's own domain). This showed up because of a virus on their client space that honestly reported the sender's address (Zafi) when it was sent to us. There is another class of false-positives, which is those nuisance bogus virus notifications, but those are heavily weighted on my system with more text filters, so those never make it to a mailbox. I don't do anything to try andcounteract those in this file. #Test definitions in my global.cfg SPFPASSspfpassx00 #Oct-07-2004 AC Reward mail that triggers SPFPASS, but only if the spammer isn't a known bad guy.SPFGOODfilter D:\IMail\Declude\SPFGood.txtx00 #Contents of SPFGOOD TESTSFAILED END NOTCONTAINS SPFPASS TESTSFAILED END CONTAINS SBLTESTSFAILED END CONTAINS MPBLTESTSFAILED END CONTAINS SNIFFERTESTSFAILED END CONTAINS SPAMDOMAINSTESTSFAILED END CONTAINS SPAMDOMMAILCOMTESTSFAILED END CONTAINS SPAMDOMLOCALTESTSFAILED END CONTAINS MAILPOLICETESTSFAILED END CONTAINS HIL #We may need to add extra exclusions here, for badly implemented SPF records#that we're not interested in helping, e.g. dccnet.com lists PTR in the#record, but all of their dynamic client IP space also ends with this,#which essentially lets all their viruses and junk come from them. REVDNS END ENDSWITH .dccnet.com # If we get this far, SPFPASS was triggered and the bad guy isn't a#well-known spammer. It may be a dynamic IP, though. I'm not testing#against those, because I think it is more likely that if someone has#SPFPASS, then the dynamic IP listing is the false positive. This may#change when spammers try to make smarter use of their trojan'ed zombie#machines and create more 'infrastructure' with them on disposable#domain names. REMOTEIP -7 CONTAINS . #Let's also check if they are an IADB member see X-IADB-URL#http://www.isipp.com/iadb.php#This should really be a completely separate test with verification, but#maybe later. HEADERS -5 CONTAINS X-IADB- -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kami RazvanSent: Friday, December 24, 2004 8:17 AMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] SPF Success Hi; I have added a couple of filters that work quite well using SPF. Although by itself it does not do much but as a combination it is working for us. Towards the end of the filters I have a couple of combo filters that I called [Elevate.?] where ? is the category of elevate weight. The [Elevate.SPF.Fail] is as follows: SKIPIFWEIGHT 50 TESTSFAILEDEND NOTCONTAINS [SPF.FAIL]TESTSFAILEDENDNOTCONTAINS [COMBO.LINK] TESTSFAILED0CONTAINS[NOLEGITCONTENT]TESTSFAILED0CONTAINS[HEURTESTSFAILED0CONTAINS[REVDNS] - the Combo.Link filter is a set of filters that detects if the email has any image or URL links in the body. Here is the [COMBO.LINK] filter: SKIPIFWEIGHT 50 TESTSFAILED 0 CONTAINS [LINK.BODY] TESTSFAILED 0 CONTAINS [LINK.BODY.IP]TESTSFAILED 0 CONTAINS [EMAIL PROTECTED]TESTSFAILED 0 CONTAINS [LINK.BODY.IMAGE] [ELEVATE.SPF.FAIL]has 100% hit on spam that might have gotten through or not deleted. I have not seen a false positivebut of course it does not mean it won't on other systems. Regards, Kami
[Declude.JunkMail] SPF Success
I'm setting up SPF. Just wondering what success SPF has had with marking spam for anyone? --- [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.
Re: [Declude.JunkMail] SPF Success
Middling success, but definitely beneficial...the biggest benefit we've seen is in blocking forged spam from domains we serve. By implementing SPF for those domains, we can fail email that doesn't come from our servers. So, forging spam that uses the destination address as the from address is easily caught. Darin. - Original Message - From: Danny [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Thursday, December 23, 2004 8:48 PM Subject: [Declude.JunkMail] SPF Success I'm setting up SPF. Just wondering what success SPF has had with marking spam for anyone? --- [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. --- [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.
Re: [Declude.JunkMail] SPF record
Title: SPF record I would either put the private IP in the SPF record, use WHITELIST AUTH to whitelist users who authenticate with the SMTP server, or counterbalance the SPF test failure weight with an IP whitelist. Darin. - Original Message - From: Agid, Corby To: [EMAIL PROTECTED] Sent: Friday, December 10, 2004 4:29 PM Subject: [Declude.JunkMail] SPF record Hello, Perhaps this is the wrong place to ask. If so, please let me know. We have Imail/Declude installed on a private network, and is accessed through a firewall that has our public address. I have put an SPF record on our public DNS server. As far as I can tell, it's correct and working as it should EXCEPT when one user of our domain sends mail to another user on our domain. In that case, we get a failure.. My hunch is that the SPF test is basing it's decision on the private network address which is NOT contained in the SPF record. If that's the case, would it be appropriate to put the private address in the SPF record .that seems wrong. Is there another option for the SPF record that covers this situation? Any thoughts? Corby
RE: [Declude.JunkMail] SPF record
Title: SPF record Yes, the Whitelist Auth seems to be the best solution. I would think publishing a private IP address ina DNS record would be strange. Thanks for your help. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin CoxSent: Friday, December 10, 2004 1:48 PMTo: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] SPF record I would either put the private IP in the SPF record, use WHITELIST AUTH to whitelist users who authenticate with the SMTP server, or counterbalance the SPF test failure weight with an IP whitelist. Darin. - Original Message - From: Agid, Corby To: [EMAIL PROTECTED] Sent: Friday, December 10, 2004 4:29 PM Subject: [Declude.JunkMail] SPF record Hello, Perhaps this is the wrong place to ask. If so, please let me know. We have Imail/Declude installed on a private network, and is accessed through a firewall that has our public address. I have put an SPF record on our public DNS server. As far as I can tell, it's correct and working as it should EXCEPT when one user of our domain sends mail to another user on our domain. In that case, we get a failure.. My hunch is that the SPF test is basing it's decision on the private network address which is NOT contained in the SPF record. If that's the case, would it be appropriate to put the private address in the SPF record.that seems wrong. Is there another option for the SPF record that covers this situation? Any thoughts? Corby
RE: [Declude.JunkMail] SPF record
I decided to use the Whitelist Auth to handle this. Our clients are often outside the firewall when they send mail to each other, so adding an entry to the private DNS won't help. I wasn't familiar with the Auth until your posting...up til recently our declude box was merely a mail proxy for the internal Exchange box. Thanks again -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Morgan Sent: Friday, December 10, 2004 1:52 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] SPF record We have Imail/Declude installed on a private network, and is accessed through a firewall that has our public address. I have put an SPF record on our public DNS server. As far as I can tell, it's correct and working as it should EXCEPT when one user of our domain sends mail to another user on our domain. In that case, we get a failure.. My hunch is that the SPF test is basing it's decision on the private network address which is NOT contained in the SPF record. On my private network, I have a DNS server that provides the private IP address of my email server to my inside users. I just added an internal SPF text record to that DNS server. If all of your internal users use AUTH or you whitelist your internal IP addresses, then the SPF failure is just an annoyance. Regards, Brad Morgan IT Manager Horizon Interactive Inc. --- [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. --- [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.
[Declude.JunkMail] SPF record
Title: SPF record Hello, Perhaps this is the wrong place to ask. If so, please let me know. We have Imail/Declude installed on a private network, and is accessed through a firewall that has our public address. I have put an SPF record on our public DNS server. As far as I can tell, it's correct and working as it should EXCEPT when one user of our domain sends mail to another user on our domain. In that case, we get a failure.. My hunch is that the SPF test is basing it's decision on the private network address which is NOT contained in the SPF record. If that's the case, would it be appropriate to put the private address in the SPF record.that seems wrong. Is there another option for the SPF record that covers this situation? Any thoughts? Corby
RE: [Declude.JunkMail] SPF record
We have Imail/Declude installed on a private network, and is accessed through a firewall that has our public address. I have put an SPF record on our public DNS server. As far as I can tell, it's correct and working as it should EXCEPT when one user of our domain sends mail to another user on our domain. In that case, we get a failure.. My hunch is that the SPF test is basing it's decision on the private network address which is NOT contained in the SPF record. On my private network, I have a DNS server that provides the private IP address of my email server to my inside users. I just added an internal SPF text record to that DNS server. If all of your internal users use AUTH or you whitelist your internal IP addresses, then the SPF failure is just an annoyance. Regards, Brad Morgan IT Manager Horizon Interactive Inc. --- [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.
Re: [Declude.JunkMail] SPF question
Thanks, Scott. Ben - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 21, 2004 2:42 PM Subject: Re: [Declude.JunkMail] SPF question I have a question about setting up the SPF string. If I use this string: v=spf1 a mx a:bcw5, a:bcw6 -all as a text record in our domain (bcwebhost.net), then the SPF test checks the sending IP and tries to match it against either bcw5.bcwebhost.net or bcw6.bcwebhost.net. The -all option says that if the sending IP doesn't match one of those two, the test fails. Now when I send out mail, it goes out through an IP (66.224.41.4 -- our firewall) that doesn't belong to that domain. So how do I get the SPF test to pass for email coming from this IP address? You just need to add ip4:66.224.41.4 to the SPF record, and you should be all set. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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. --- [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.
[Declude.JunkMail] SPF question
Hi, I have a question about setting up the SPF string. If I use this string: v=spf1 a mx a:bcw5, a:bcw6 -all as a text record in our domain (bcwebhost.net), then the SPF test checks the sending IP and tries to match it against either bcw5.bcwebhost.net or bcw6.bcwebhost.net. The -all option says that if the sending IP doesn't match one of those two, the test fails. Now when I send out mail, it goes out through an IP (66.224.41.4 -- our firewall) that doesn't belong to that domain. So how do I get the SPF test to pass for email coming from this IP address? Thanks, Ben BC Web --- [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.
Re: [Declude.JunkMail] SPF question
I have a question about setting up the SPF string. If I use this string: v=spf1 a mx a:bcw5, a:bcw6 -all as a text record in our domain (bcwebhost.net), then the SPF test checks the sending IP and tries to match it against either bcw5.bcwebhost.net or bcw6.bcwebhost.net. The -all option says that if the sending IP doesn't match one of those two, the test fails. Now when I send out mail, it goes out through an IP (66.224.41.4 -- our firewall) that doesn't belong to that domain. So how do I get the SPF test to pass for email coming from this IP address? You just need to add ip4:66.224.41.4 to the SPF record, and you should be all set. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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.
Re: [Declude.JunkMail] SPF HABEAS
After reading this article on SPF I am wondering about the merits of SPF: http://securitypronews.com/news/securitynews/spn-45-2004090816PercentofSpammersAdoptSPFEmailAuthenticationScheme.html Is SPF going to be exploited to the point where is is of little value? That is good news -- that means that you can catch 16% of spammers with a blacklist of domain names of spammers that use SPF. :) Now, someone just needs to start working on that list. Also is anyone using the WHITELIST HABEAS test? Are there any pros or cons to activating this test? Right now, it isn't of much benefit, since spammers started using it a while ago, and couldn't get caught. Even Habeas reps have admitted that the Habeas headers aren't as useful as had originally been hoped. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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.
Re: [Declude.JunkMail] SPF HABEAS
- Original Message - From: R. Scott Perry [EMAIL PROTECTED] Also is anyone using the WHITELIST HABEAS test? Are there any pros or cons to activating this test? Right now, it isn't of much benefit, since spammers started using it a while ago, and couldn't get caught. Even Habeas reps have admitted that the Habeas headers aren't as useful as had originally been hoped. Like Scott said, don't rely on the Habeas headers, they are almost worthless now. However, you can use their RBL white/black lists very effectively with Declude JunkMail: HABEAS-USER ip4r sa-hul.habeas.com * -10 0 HABEAS-VIOLATOR ip4r sa-hil.habeas.com * 10 0 Habeas maintains these lists and adds REAL customers to the whitelist and violators to the blacklist, so this work much better and more effectively than there Habeas headers ever did. Oh, and remember to disable the Habeas test if you are using it with Declude JunkMail: #HABEAS habeas x x -3 0 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.
Re: [Declude.JunkMail] SPF issue
- Original Message - From: Imail Admin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 30, 2004 11:47 Subject: Re: [Declude.JunkMail] SPF issue I've been just begging for motivation to upgrade from 7.15 to 8.x, and so far, the only good reason I've found is the WHITELIST AUTH feature. Otherwise, it's hard to see any reason for upgrading, especially when I've got a stable, trouble-free mail server now, and an upgrade could introduce any number of new problems. Now if someone could just convince Ipswitch to do something significant with IMail (better calendaring, improved list server, support for ASP in web pages, better handling of IMAP, and so on), I'd jump to the upgrade in a snap. In the meanwhile, I'm with David: we sit at 7.15 and just work around the absence of WHITELIST AUTH. It may be painful, but it seems likely that I'm going to have to split up my DNS using Bind 9 views, which means groan two zone files for each domain we host, an internal one with an SPF record that permits sending from all our IPs, and an external one that only permits the MTAs to do it. I'm not terribly happy about this, as it's going to make my DNS config very perplexing just a few months after I had finished a major cleanup. It would be better if Declude would just simply have some way of whitelisting IP addresses to prevent SPF testing. We aren't going to spend money on an upgrade path just for WHITELIST AUTH, that's for certain. -- A. Clausen [EMAIL PROTECTED] --- [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.
Re: [Declude.JunkMail] SPF issue
I've been just begging for motivation to upgrade from 7.15 to 8.x, and so far, the only good reason I've found is the WHITELIST AUTH feature. Otherwise, it's hard to see any reason for upgrading, especially when I've got a stable, trouble-free mail server now, and an upgrade could introduce any number of new problems. Now if someone could just convince Ipswitch to do something significant with IMail (better calendaring, improved list server, support for ASP in web pages, better handling of IMAP, and so on), I'd jump to the upgrade in a snap. In the meanwhile, I'm with David: we sit at 7.15 and just work around the absence of WHITELIST AUTH. Ben Bednarz BC Web - Original Message - From: Kevin Bilbee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 4:42 PM Subject: RE: [Declude.JunkMail] SPF issue No, the probem you are having is with your own mail server catching messages from your subscribers sending mail. If you do not allow mail relay and only auth then you can whitelist your dial up ip address of your users within declude. Now if they are not connecting from one of your dial up ranges then they will be caught with the SPF record. Many features of declude are muted by not using WHITELIST AUTH and not being on the 8.x version of imail. Kevin Bilbee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of R. Scott Perry Sent: Wednesday, September 29, 2004 4:09 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] SPF issue Unfortunately i'm running imail 7.07 and it doesn't look like we'll be going to 8.x anytime soon. So, if i change my spf record to include the ip pool of my dialup users, i should be ok, correct? That would be fine. or, i could change the -all to ~all, correct? That could work, although it has two drawbacks: many SPF systems don't support softfail yet, and it reduces the effectiveness of your SPF record. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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. --- [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. --- [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.
[Declude.JunkMail] SPF issue
I thought i had a handle on this SPF stuff, but i think i've got something wrong in my understanding. I've set up my SPF record for our domain with the following record: choicenet1.com v=spf1 ip4:207.170.239.11 ip4:207.170.239.4 a mx -all From my understanding of this, the ip4's are extra ip addy's that should be "allowed" to send email AS this domain. The mx entry states that the ip addy of the mx record(s) found for this domain are also "allowed" to send email AS this domain. Am I right so far? Now, my dialup customers are on a different subnet and log into our imail server using smtp auth. When they send emails out, shouldn't the ip addy of the email then take on the ip addy of the email server in the eyes of the receiving mail server? the reason i ask this is because of the following in my spf.log: 216.64.178.28 [EMAIL PROTECTED] [dona]: FAIL: v=spf1 ip4:207.170.239.11 ip4:207.170.239.4 a mx -all There are lots of failures in the log and the ip address on the far left is an ip addy in the ip pool of our max tnt for our dial up customers, not the ip addy of the email server. I see this for just about every one of my users, so for now, i've turned off SPF. Can someone explain why/where i am going wrong? Is this a case of standard version vs. pro version and declude is just logging all "outbound" attempts and throwing me off? that makes me wonder though, why am i even seeing these since they are "leaving" my mail server to go to others. it should be in their log files.right? thanks for any help provided! (running Junkmail Standard version 1.79) David Dresler
Re: [Declude.JunkMail] SPF issue
Now, my dialup customers are on a different subnet and log into our imail server using smtp auth. When they send emails out, shouldn't the ip addy of the email then take on the ip addy of the email server in the eyes of the receiving mail server? No. Otherwise, it would defeat the purpose of SPF: A spammer could connect to your mailserver and send out spam. What you can do in this case (if you are running IMail v8) is add a line WHITELIST AUTH to your \IMail\Declude\global.cfg file, to whitelist all users that authenticate. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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.
RE: [Declude.JunkMail] SPF issue
No, the probem you are having is with your own mail server catching messages from your subscribers sending mail. If you do not allow mail relay and only auth then you can whitelist your dial up ip address of your users within declude. Now if they are not connecting from one of your dial up ranges then they will be caught with the SPF record. Many features of declude are muted by not using WHITELIST AUTH and not being on the 8.x version of imail. Kevin Bilbee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of R. Scott Perry Sent: Wednesday, September 29, 2004 4:09 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] SPF issue Unfortunately i'm running imail 7.07 and it doesn't look like we'll be going to 8.x anytime soon. So, if i change my spf record to include the ip pool of my dialup users, i should be ok, correct? That would be fine. or, i could change the -all to ~all, correct? That could work, although it has two drawbacks: many SPF systems don't support softfail yet, and it reduces the effectiveness of your SPF record. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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. --- [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.
[Declude.JunkMail] SPF
I was hoping someone could help me with SPF settings. Currently any domain that has an unknown SPF, is not supported or does not exist has -3 (same as SPF pass) applied to the overall total. I found the log file spf.none that has these domains listed. How do I get 0 points applied if a domain is unknown? If a domain doesn't have an SPF recorded I certainly don't want points subtracted. I checked in the declude log file and it is listed as nspfpass -3 but doesn't show up in the email header as does SPFPASS and SPFFAIL. How do I change this behavior? Do I add a nspfpass to the global.cfg? Here are my current settings spfpass spf pass x 0 -3 spffail spf fail x 0 -3 --- [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.
Re: [Declude.JunkMail] SPF
I was hoping someone could help me with SPF settings. Currently any domain that has an unknown SPF, is not supported or does not exist has -3 (same as SPF pass) applied to the overall total. spfpass spf pass x 0 -3 spffail spf fail x 0 -3 With these settings, any E-mail that does not pass and/or does not fail SPF (every E-mail!) will have 3 points subtracted from its weight. I would recommend changing those lines to to: SPFPASS spf passx -3 0 SPFFAIL spf failx 3 0 That will subtract 3 points if the E-mail passes SPF, add 3 points if it fails SPF, and will do nothing if there is an UNKNOWN response (for example, if there is no SPF record). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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.
[Declude.JunkMail] SPF Envelope Rewriting
We've implemented SPF for all the domains we do mail hosting for, and have enabled SPF checking on Declude. Only one thing remains, and that is the issue of message envelopes. The big thing that busts SPF is a message forwarding, and the only way around this is to rewrite the envelope. I know IMail has no support for this, and I have my doubts it ever will. I was wondering if there are any plans for this in Declude, which does seem to have some ability to add headers. My only alternative is turn this task over to my Postfix relay server (guarding the IMail server for distributed dictionary attacks), but I'm hoping for something simpler because, well, I'm just plain lazy. -- A. Clausen [EMAIL PROTECTED] --- [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.
Re: [Declude.JunkMail] SPF Envelope Rewriting
We've implemented SPF for all the domains we do mail hosting for, and have enabled SPF checking on Declude. Only one thing remains, and that is the issue of message envelopes. The big thing that busts SPF is a message forwarding, and the only way around this is to rewrite the envelope. This is something that we will be looking into. I can't make any guarantees that we'll be able to do it (it may not be technically possible, or it may be extremely difficult), however. --- [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.
[Declude.JunkMail] SPF 2.0 ?
Title: Message Hi, Does Declude correctly interprete the SPF records published by Hotmail/MSN? E.g., currently we publish something like this... v=spf1 mx ip4:216.124.168.0/28include:webhost.hm-software.com -all but the new format would look like that: spf2.0/pra mx ip4:216.124.168.0/28 include:webhost.hm-software.com -all I don't care which format I have to use for my own domains- but obviously, I'd expectDeclude to help me block Hotmail/MSNimpersonations (and for that matter, all these other domains who are now being set up because of Microsoft's publicity.) I have been contacted by several clients who want "SenderID" information added to their DNS. If that's representative, then the adoption rate should skyrocket next month, and I sure would like to benefit from it! If do have a maintenance agreement, so I have no problem downloading/installing Declude updates. Best RegardsAndy SchmidtHM Systems Software, Inc.600 East Crescent Avenue, Suite 203Upper Saddle River, NJ 07458-1846Phone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206http://www.HM-Software.com/
Re: [Declude.JunkMail] SPF 2.0 ?
Does Declude correctly interprete the SPF records published by Hotmail/MSN? E.g., currently we publish something like this... v=spf1 mx ip4:216.124.168.0/28 include:webhost.hm-software.com -all but the new format would look like that: spf2.0/pra mx ip4:216.124.168.0/28 include:webhost.hm-software.com -all I believe those are actually Sender-ID: records, not SPF records. It's unclear right now what the status of SPF and Sender-ID are, and what *should* be done (should you publish SPF records or Sender-ID: records? should you check one or both? etc.). Once things get straightened out, we'll investigate the situation further. The last thing we want to do now is put in a lot of development effort for Microsoft's Sender-ID only to find out that due to the patent nobody uses it, and people are only going to use SPF. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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.
Re: [Declude.JunkMail] SPF 2.0 ?
Message- Original Message - From: Andy Schmidt I have been contacted by several clients who want SenderID information added to their DNS. If that's representative, then the adoption rate should skyrocket next month, and I sure would like to benefit from it! If do have a maintenance agreement, so I have no problem downloading/installing Declude updates. Have your customers take a look at: http://apache.org/foundation/docs/sender-id-position.html http://apache.slashdot.org/article.pl?sid=04/09/02/1446229tid=148tid=155; 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.
RE: [Declude.JunkMail] SPF 2.0 ?
Hi Scott: I wonder if others on this list have seen inquiries from their hosting customers indicating that there will be some good number of domains who will support it. Besides I have seen Declude jump on some pretty irrelevant proposals in the last year. Compared to that SenderID will be relevant from Day 1, if it helps me to block MSN and Hotmail impersonators. I can't think of any good reason NOT to support it, even if it was MSN and Hotmail only. These two domains achieve is all that's needed to achieve critical mass. No? Especially, since it appears to me as if the syntax of SPF 2.0 vs. SPF1 appears so closely related (if not mostly identical) and the development effort is probably a fraction of what was spent to set up SPF1 originally? Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ --- [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.
Re: [Declude.JunkMail] SPF 2.0 ?
Good luck trying to rally support around this one. If the open source community is not going to support it, and none of Microsoft's competitors (Yahoo, AOL, GMail, etc.), then what makes you think that other ISPs and companies are going to rally around SenderID, especially when their are other competing standards that are not so encumbered by patents and licenses as SenderID is? Bill - Original Message - From: Andy Schmidt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 20, 2004 10:55 AM Subject: RE: [Declude.JunkMail] SPF 2.0 ? Hi, Nope, they don't read Apache announcements. They want to make sure that they can send newsletters to their MSN and Hotmail subscribers and want the appropriate records added to their domains. Now, if my clients (and possibly other hosters' clients) demand those TXT records to be added (which they are entitled to), then I give a horse's butt about Apache, Unix and any other political faction. As a provider, I'm must being pragmatic - if there is a significant number of domains that have DNS TXT records with SPF2.0 information, then I sure hope that the leading anti-Spam software (Declude) will exploit those TXT records for MY benefit. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ --- [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. --- [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.
Re: [Declude.JunkMail] SPF 2.0 ?
- Original Message - Correct. But there are also the patent issues, and the muckiness of it all (I'm having troubles even finding an official Microsoft document that documents this new Sender-ID). Here you go: Sender ID (Published: June 23, 2004 | Updated: July 12, 2004) http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx and Sender ID - Executive Overview (Published: July 12, 2004) http://download.microsoft.com/download/c/0/4/c0412bf5-86f9-42fa-9f67-59a166c13a77/senderid_exec.pdf and Sender ID - Deployment Overview for E-Mail Senders (Published: July 12, 2004) http://download.microsoft.com/download/9/e/d/9ed3b337-7a53-4fd8-bd3e-6c483a2b669a/senderid_deploy.pdf and Sender ID Draft Specification: MTA Authentication Records in DNS (Published June 23, 2004) http://download.microsoft.com/download/d/a/2/da2821f5-6acb-4058-8974-5a3c7d187794/senderid.pdf 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.
RE: [Declude.JunkMail] SPF 2.0 ?
Hi Scott: But how are they hearing about the Sender-ID records in the first place? Virtually everything points to real SPF. Apparently, Microsoft has been promoting SenderID to email mailing houses (see: http://www.exacttarget.com/) and to their network of Microsoft Partners, who in turn are educating their customers. I've had several inquiries by large clients in the past 2 weeks. Example, one client writes me: I sat through a webinar last week that talked about sender ID and the new requirements of the CAN-SPAM law. To be fair, they disclose the fact that the patent issues may lead to a DIFFERENT standard down the road - but that for now, the Microsoft sites will use it and that's critical mass enough: When do I need to Implement? Microsoft plans to start checking for Sender ID records in October of 2004, so we recommend you publish records by 10/1/04. Will the IETF approve Sender ID as a standard? There has been lots of talk of this recently. The Internet Engineering Task Force (IETF) has witheld their support for Sender ID due to a pending patent by Microsoft on the technology. The IETF will only approve license-free technologies as standards. This means that though we may eventually have a different standard from the IETF, all signs still point to Microsoft using Sender ID, so compliance with it is highly recommended. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ --- [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.
