RE: [nznog] SPF Uptake in New Zealand
Hey folks, Noone has mentioned building the SPF strings :) I found this a while back: http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx It's a nice little (online) wizard from MS, which allows you to build the string without having to work out a geekcode-look-alike. AFAIK, they don't store info - just show you the SPF for what you enter. No comment on how effective SPF might be, but the wizard is handy if you don't wanna work out the syntax :) Cheers. Nic, off to add the TXT record to his domains. -- Nic Wise - Senior Developer - Microsoft MVP (.NET) AfterMail Limited. t. +64.21.676.418 w. http://www.aftermail.com/ e. nic.wise(a)aftermail.com b. http://www.fastchicken.co.nz/blog/
Nic Wise wrote:
Hey folks,
Noone has mentioned building the SPF strings :) I found this a while back:
http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx
It's a nice little (online) wizard from MS, which allows you to build the string without having to work out a geekcode-look-alike. AFAIK, they don't store info - just show you the SPF for what you enter.
Microsoft pwns SPFv1 and calls it SenderID. A tip on the Spamtools list said to bear in mind that it's mostly spammers and bulkers who publish such records. Therefore, rejecting mail based on the existence of the records might indeed be useful. -- Juha
Microsoft pwns SPFv1 and calls it SenderID.
A tip on the Spamtools list said to bear in mind that it's mostly spammers and bulkers who publish such records. Therefore, rejecting mail based on the existence of the records might indeed be useful.
You should only reject on SPF if the rule says so. Yes alot of spammers have set up SPF records.. but SPF is not designed for Stopping Spam. Xtra have only set "v=spf1 ip4:210.86.15.0/24 ?all" instead of "v=spf1 ip4:210.86.15.0/24 -all" The existing record will make the result neutral (tested for SPF but still allowed to come in) instead of fail for people testing for it. If they set "v=spf1 ip4:210.86.15.0/24 -all" then some mail (for example that trademe.co.nz sends out) would get rejected as it would be coming from the wrong place Thanks Craig
If they set "v=spf1 ip4:210.86.15.0/24 -all" then some mail (for example that trademe.co.nz sends out) would get rejected as it would be coming from the wrong place
This was a little unclear what I said . trademe.co.nz sends out emails sometimes from the email address of the trademe user. If a user has email address of customer(a)xtra.co.nz it will send from that address from trademe mail server. and if tested for SPF with a -all will fail and get rejected. Thanks Craig
On Thu, 14 Jul 2005 14:11, Craig Whitmore wrote:
If they set "v=spf1 ip4:210.86.15.0/24 -all" then some mail (for example that trademe.co.nz sends out) would get rejected as it would be coming from the wrong place
This was a little unclear what I said . trademe.co.nz sends out emails sometimes from the email address of the trademe user. If a user has email address of customer(a)xtra.co.nz it will send from that address from trademe mail server. and if tested for SPF with a -all will fail and get rejected.
Shouldn't the '-all' you are talking about be '~all'? Also to fix their problem trademe should possibly be sending mail with the Reply-to set to the users email and the From set to themselves. hads -- hubub, hubub, HUBUB, hubub, hubub, hubub, HUBUB, hubub, hubub, hubub.
Noone has mentioned building the SPF strings :) I found this a while back:
http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx
It's a nice little (online) wizard from MS, which allows you to build the string without having to work out a geekcode-look-alike. AFAIK, they don't store info - just show you the SPF for what you enter.
Be carefull. Sender-ID is not SPF.. Microsoft took SPF and added some changes to it (which alot of people in the SPF "community" think make it worse than simple SPF by itself.). Sender-ID has their own records (see nslookup -type=txt spam.co.nz). but will use the SPF records if there is no SenderID record (spf2.0) and this may make Sender-ID give false possitives at rare times. (the reusage of Microsoft of the SPF tag is what SPF people don't like), but when everyone starts using the new RR of "SPF" instead of TXT for SPF., microsoft can do what they want, as it was given for SPF not Sender-ID). Thanks Craig
Craig Whitmore wrote:
Be carefull. Sender-ID is not SPF.. Microsoft took SPF and added some changes to it (which alot of people in the SPF "community" think make it worse than simple SPF by itself.). Sender-ID has their own records (see nslookup -type=txt spam.co.nz). but will use the SPF records if there is no SenderID record (spf2.0) and this may make Sender-ID give false possitives at rare times. (the reusage of Microsoft of the SPF tag is what SPF people don't like), but when everyone starts using the new RR of "SPF" instead of TXT for SPF., microsoft can do what they want, as it was given for SPF not Sender-ID).
$ host -t txt spam.co.nz spam.co.nz descriptive text "v=spf1 ip4:219.88.242.0/27 -all" spam.co.nz descriptive text "spf2.0/pra ip4:219.88.242.0/27 -all" spam.co.nz descriptive text "Professional DNS Management by Orcon Internet" $ host -t txt microsoft.co.nz {nothing} $ host -t txt microsoft.com microsoft.com descriptive text "v=spf1 mx redirect=_spf.microsoft.com" $ host -t txt _spf.microsoft.com _spf.microsoft.com descriptive text "v=spf1 ip4:213.199.128.139 ip4:213.199.128.145 ip4:207.46.50.72 ip4:207.46.50.82 ip4:131.107.3.116 ip4:131.107.3.117 ip4:131.107.3.100 ip4:131.107.3.108 a:delivery.pens.microsoft.com a:mh.microsoft.m0.net mx:microsoft.com ?all" Humm... -- Juha
participants (4)
-
Craig Whitmore -
Hadley Rich -
Juha Saarinen -
Nic Wise