Apply best-guess policy for domains without SPF records ?
Apply best-guess policy for domains without SPF records ?
I noticed an option in the SPF section of the security tab of the SNTP connector which says:
"Apply best-guess policy for domains without SPF records" and has an empty text box next to it.
There no reference to it in the manual, how does this work?
Thanks in Advance
"Apply best-guess policy for domains without SPF records" and has an empty text box next to it.
There no reference to it in the manual, how does this work?
Thanks in Advance
-Andres Tinoco
PuntoWEB de Venezuela C.A.
PuntoWEB de Venezuela C.A.
-
- Posts: 5858
- Joined: Fri Jan 16, 2004 6:49 am
- Location: Melbourne
Hi the new version will have new manuals but here is the reference from the new manual in regards to the best guess feature;
Apply best guess policy for domains without SPF records: For connections that do not have an SPF record further checks can be added in their place. A subsequent check could be done on an MX record or even an A record for the domain lookup.
Apply best guess policy for domains without SPF records: For connections that do not have an SPF record further checks can be added in their place. A subsequent check could be done on an MX record or even an A record for the domain lookup.
Regards,
Product Services
MailEnable Pty Ltd
To keep track of all ME company updates and version releases you should subscribe to the MailEnable list at http://www.mailenable.com or the RSS feed http://www.mailenable.com/rss.
Product Services
MailEnable Pty Ltd
To keep track of all ME company updates and version releases you should subscribe to the MailEnable list at http://www.mailenable.com or the RSS feed http://www.mailenable.com/rss.
I have played with this feature a little bit this week... Here's how I'm assuming (and so far, observing) it works. If anyone with more knowledge about this feature knows differently, please let us know....
When mail comes in from a domain for which there is no SPF configured, this feature will apply a "catch-all" generic SPF policy that you specify in this field. If you have enabled "Add Received-SPF header for unauthenticated senders", MailEnable will add "Received-SPF: pass", "softfail", "hardfail", etc. headers to the message, according to the policy you provide.
I'm assuming this policy should be very generic and "soft" to avoid blocking lots of legitimate mail. Perhaps it should be configured to never "hardfail" a message, so you can sort messages at the client with simple rules based on the Received-SPF header.
With a policy like "mx ~all" you would get a "pass" header for all mail coming from a domain's real mail exchanger, and a "softfail" for mail coming from any other IP. The message would then be forwarded to the recipient, and you could use filter rules on the client to sort "softfail" messages into a "Possibly Spam" folder.
This sounds good, but even with a very loose policy like "mx a ptr ~all", I find that most of the messages that it marks "softfail" are legitimate mail. Does anybody have a better understanding of SPF, or any other suggestions for this field?
I'm also curious if any client-level anti-spam software takes the Received-SPF header into account in it's calculations (predicting that a "softfail" is more likely to be SPAM than a "neutral", and using this as just one of many heuristics to decide whether to junk the message or not).
-Tom Rusnock
When mail comes in from a domain for which there is no SPF configured, this feature will apply a "catch-all" generic SPF policy that you specify in this field. If you have enabled "Add Received-SPF header for unauthenticated senders", MailEnable will add "Received-SPF: pass", "softfail", "hardfail", etc. headers to the message, according to the policy you provide.
I'm assuming this policy should be very generic and "soft" to avoid blocking lots of legitimate mail. Perhaps it should be configured to never "hardfail" a message, so you can sort messages at the client with simple rules based on the Received-SPF header.
With a policy like "mx ~all" you would get a "pass" header for all mail coming from a domain's real mail exchanger, and a "softfail" for mail coming from any other IP. The message would then be forwarded to the recipient, and you could use filter rules on the client to sort "softfail" messages into a "Possibly Spam" folder.
This sounds good, but even with a very loose policy like "mx a ptr ~all", I find that most of the messages that it marks "softfail" are legitimate mail. Does anybody have a better understanding of SPF, or any other suggestions for this field?
I'm also curious if any client-level anti-spam software takes the Received-SPF header into account in it's calculations (predicting that a "softfail" is more likely to be SPAM than a "neutral", and using this as just one of many heuristics to decide whether to junk the message or not).
-Tom Rusnock
hi there,trusnock wrote:I have played with this feature a little bit this week... Here's how I'm assuming (and so far, observing) it works. If anyone with more knowledge about this feature knows differently, please let us know....
When mail comes in from a domain for which there is no SPF configured, this feature will apply a "catch-all" generic SPF policy that you specify in this field. If you have enabled "Add Received-SPF header for unauthenticated senders", MailEnable will add "Received-SPF: pass", "softfail", "hardfail", etc. headers to the message, according to the policy you provide.
I'm assuming this policy should be very generic and "soft" to avoid blocking lots of legitimate mail. Perhaps it should be configured to never "hardfail" a message, so you can sort messages at the client with simple rules based on the Received-SPF header.
With a policy like "mx ~all" you would get a "pass" header for all mail coming from a domain's real mail exchanger, and a "softfail" for mail coming from any other IP. The message would then be forwarded to the recipient, and you could use filter rules on the client to sort "softfail" messages into a "Possibly Spam" folder.
This sounds good, but even with a very loose policy like "mx a ptr ~all", I find that most of the messages that it marks "softfail" are legitimate mail. Does anybody have a better understanding of SPF, or any other suggestions for this field?
I'm also curious if any client-level anti-spam software takes the Received-SPF header into account in it's calculations (predicting that a "softfail" is more likely to be SPAM than a "neutral", and using this as just one of many heuristics to decide whether to junk the message or not).
-Tom Rusnock
im monitoring my SPF too....especially HOTMAIL domain.
Hotmail SPF was very good but some how, spam are still coming from their domain like "randam charator@hotmail.com"
and i can say that if the SPF is configure properly, and the result is SOFTFAIL, i take is as SPAM mail.
In myME this will trigger the SPF filter on my ME to add in a header SOFTFAIL.
the problem now is if want all hotmail softfail mail foward to another email address, how to do that ?
i enable the criteria "Where the header contain: hotmail" and also "where the SPF result : softfail"
but this filter filter others domain softfail also....
hwo to correct it ?
Very "solid" replies here, just what i needed. TY for sharing this.With a policy like "mx ~all" you would get a "pass" header for all mail coming from a domain's real mail exchanger, and a "softfail" for mail coming from any other IP. The message would then be forwarded to the recipient, and you could use filter rules on the client to sort "softfail" messages into a "Possibly Spam" folder.
This sounds good, but even with a very loose policy like "mx a ptr ~all", I find that most of the messages that it marks "softfail" are legitimate mail. Does anybody have a better understanding of SPF, or any other suggestions for this field?
I will experiment and keep you guys updated, I think i will try this setting: "mx a ptr ~all"
-Andres Tinoco
PuntoWEB de Venezuela C.A.
PuntoWEB de Venezuela C.A.
-
- Posts: 844
- Joined: Mon Dec 05, 2005 7:51 am
- Location: Canada
here is a better solution
"a/16 mx/16 ~all"
this will open up the spf to other sending servers on the same Class C network. some people like to use /24, but i have found that spammers spoofing a domain do not have IP's on the same Class C network. ... it is good for people who host on mega networks like GoDaddy or Brinkster.
Here is a reference for you:
CIDR Class Hosts* Mask
/32 1/256 C 1 255.255.255.255
/31 1/128 C 2 255.255.255.254
/30 1/64 C 4 255.255.255.252
/29 1/32 C 8 255.255.255.248
/28 1/16 C 16 255.255.255.240
/27 1/8 C 32 255.255.255.224
/26 1/4 C 64 255.255.255.192
/25 1/2 C 128 255.255.255.128
/24 1 C 256 255.255.255.000
/23 2 C 512 255.255.254.000
/22 4 C 1024 255.255.252.000
/21 8 C 2048 255.255.248.000
/20 16 C 4096 255.255.240.000
/19 32 C 8192 255.255.224.000
/18 64 C 16384 255.255.192.000
/17 128 C 32768 255.255.128.000
/16 256 C, 1 B 65536 255.255.000.000
/15 512 C, 2 B 131072 255.254.000.000
/14 1024 C, 4 B 262144 255.252.000.000
/13 2048 C, 8 B 524288 255.248.000.000
/12 4096 C, 16 B 1048576 255.240.000.000
/11 8192 C, 32 B 2097152 255.224.000.000
/10 16384 C, 64 B 4194304 255.192.000.000
/9 32768 C, 128B 8388608 255.128.000.000
/8 65536 C, 256B,1A 16777216 255.000.000.000
/7 131072 C, 512B,2A 33554432 254.000.000.000
/6 262144C,1024B,4A 7108864 252.000.000.000
/5 524288C,2048B,8A 134217728 248.000.000.000
/4 1048576C,4096B,16A 268435456 240.000.000.000
/3 2097152C,8192B,32A 536870912 224.000.000.000
/2 4194304C,16384B,64A 1073741824 192.000.000.000
/1 8388608C,32768B,128A 2147483648 128.000.000.000
"a/16 mx/16 ~all"
this will open up the spf to other sending servers on the same Class C network. some people like to use /24, but i have found that spammers spoofing a domain do not have IP's on the same Class C network. ... it is good for people who host on mega networks like GoDaddy or Brinkster.
Here is a reference for you:
CIDR Class Hosts* Mask
/32 1/256 C 1 255.255.255.255
/31 1/128 C 2 255.255.255.254
/30 1/64 C 4 255.255.255.252
/29 1/32 C 8 255.255.255.248
/28 1/16 C 16 255.255.255.240
/27 1/8 C 32 255.255.255.224
/26 1/4 C 64 255.255.255.192
/25 1/2 C 128 255.255.255.128
/24 1 C 256 255.255.255.000
/23 2 C 512 255.255.254.000
/22 4 C 1024 255.255.252.000
/21 8 C 2048 255.255.248.000
/20 16 C 4096 255.255.240.000
/19 32 C 8192 255.255.224.000
/18 64 C 16384 255.255.192.000
/17 128 C 32768 255.255.128.000
/16 256 C, 1 B 65536 255.255.000.000
/15 512 C, 2 B 131072 255.254.000.000
/14 1024 C, 4 B 262144 255.252.000.000
/13 2048 C, 8 B 524288 255.248.000.000
/12 4096 C, 16 B 1048576 255.240.000.000
/11 8192 C, 32 B 2097152 255.224.000.000
/10 16384 C, 64 B 4194304 255.192.000.000
/9 32768 C, 128B 8388608 255.128.000.000
/8 65536 C, 256B,1A 16777216 255.000.000.000
/7 131072 C, 512B,2A 33554432 254.000.000.000
/6 262144C,1024B,4A 7108864 252.000.000.000
/5 524288C,2048B,8A 134217728 248.000.000.000
/4 1048576C,4096B,16A 268435456 240.000.000.000
/3 2097152C,8192B,32A 536870912 224.000.000.000
/2 4194304C,16384B,64A 1073741824 192.000.000.000
/1 8388608C,32768B,128A 2147483648 128.000.000.000
Chase
Server 2008 Standard (x64)
ME Ent 6.51 (SQL Server 2008 Config)
ASSP 1.9
Server 2008 Standard (x64)
ME Ent 6.51 (SQL Server 2008 Config)
ASSP 1.9
-
- Posts: 844
- Joined: Mon Dec 05, 2005 7:51 am
- Location: Canada