Zen Internet Support Forum

Problem, some people want me to publish an SPF (sender Policy framework) record.

see: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-02.txt

I use mailhost.zen.co.uk as outgoing smtp server

So i thought just give as SPF TXT record

v=spf1 redirect=mailhost.zen.co.uk

or something simular

but  zen.co.uk  doesn't have a SPF record so this doesn't work

Will Zen publish an SPF record??

so that I can publish mine?

 

We aren't going to publish an SPF for zen.co.uk - this would cause problems for people sending their zen email whilst roaming for one. If you want a list of our outgoing mailserver IPs instead then PM me, but be aware these may well be changed or added to in the future, so don't rely on them forever.

NB there are problems with SPF - its not a magic fix for spam. Not 100% sure of all the issues, but I know our Core techie in charge of Zen's mail platform doesnt like SPF as it is currently implemented for some (probably good) reason which I've forgotten now.

---

Kindest regards,

James Sweet
http://www.zen.co.uk

The problem with SPF is that there are strong indications that M$/hotmailo/MSN are about to flag all mail without SPF as untrustworthy, and indicate to users of MS Express that it is bad mail, and at some later stage intend filing it in junk automatically. I too dislike SPF and realise that it solves a different problem that which upsets us all, but the power axis is about to impose it.

==John ff

Here's a couple of pages on why SPF isn't a good idea.

http://homepages.tesco.net/~J.deBoynePollard/FGA/smtp-spf-is-harmful.html

http://david.woodhou.se/why-not-spf.html

 

SPF in particular doesn't address spam routed through your ISP mail accounts in exactly the same way as your own mail.

It also relies on DNS (which isn't secure) and more specifically DNS details of the domain which is sending them mail - if that domain has been created by spammers (a simple and automated process) then it will happily vouch that all the e-mail is not spam - infact during the early days (not sure about now) the majority of SPF compliant e-mail was spam: http://www.theregister.co.uk/2004/09/03/email_authentication_spam/

SPF also breaks store and forward - a vital part of how SMTP should work. For example I work at an IT firm, one of our customers has a domain but all e-mail is sent via their ISP (demon) so when the e-mail server at our office gets a mail from them the return path shows their domain but received from shows demons mail server this is all correct but would fail an SPF check and is a very common configuration.

If you want to run SPF you should register your own domain, run a mail server and create SPF records for that domain.

The biggest problem with SPF is the false sense of security - the idea that if it enverlope of the mail passes a single test it is useful and if it fails it is spam is simply stupid. The ONLY way to really know if something is spam is too read it, we don't have time for that so we have software that tries to read it for us. Only reading the wrapper is a backwards step.

 

"We aren't going to publish an SPF for zen.co.uk"

Is this still the case ? This means either your SPF using (domain owning) using customers have to maintain a (fragile) copy of the list of Zen mail servers, or not use the SPF system at all.

I was recently the victim of a spammer using my From: address in a set of spam emails, thus flooding my mail box with bounce messages, when a simple SPF record could have prevented most of the spam arriving. 

No we don't publish SPF records. I come at this from various angles :

1) We don't restrict where our customers send email from, so it's entirely valid for a Zen customer to send from an @zen.co.uk address direct from their home system or from an Internet cafe for example. If we published SPF records that only listed our servers we'd restrict that capability. Using more lenient SPF rules would kind of defeat the point of SPF.

2) As has already been said SPF breaks any form of forwarded email, the example of given by another poster explains this. The recipient server will see the sender come from an invalid IP address. SRS (Sender Rewriting Scheme) attempts to address this. Using SRS the intermediate system (domainb.co.uk) would pass on the sender fred@domaina.co.uk as something like bounce=fred#domaina.co.uk@domainb.co.uk, thus making the new sending domain 'domainb.co.uk', and hence using its SPF rules instead. If a bounce was to occur then the email would be sent back to domainb.co.uk and the VERP'd address could be extracted to pass the bounce back on to the original sender. SPF will only fully work when every single server in the world operates it and also uses SRS.

3) SPF won't prevent spam, it will only prevent a domain being spoofed. Spammers are just as welcome to publish wildcard SPF records for their domains as anyone else :-(

I'm far more of a fan of DKIM, whereby an email is 'signed' by the sending domain. In this case it doesn't matter how many servers the email passes thro' as it's only the original sender that gets involved. Obviously only the authoritative servers for a domain can do the signing, so customers using their own servers wouldn't be able to get their @zen.co.uk email signed unless they sent via us. As with SPF there's no reason why spammers can't use DKIM except for the fact that it's a little bit more CPU intensive due to the cryptographic signing stage, which would slow them down and thus not be so desirable.

---

--
Jerry Nicholls
Principal Systems Engineer
perl -e '$_=q(print "perl -e \x27\$_=q($_);eval\x27\n");eval'

I don't think that the earlier questions relate to publishing SPF records in the domain zen.co.uk. I'm certainly more interested in Zen simply publishing an SPF record that can be included using SPF's rule composition functionality so that I can publish an SPF record saying that my own domain can send mail from Zen's SMTP relays.

For example, Google publishes an SPF record at _spf.google.com containing the current IP addresses of all of their mail relays. Look at the TXT records for that domain to see an example. As a user of "Google Apps for your Domain" (that is, gmail with a non-gmail domain) I can publish in my own SPF record the following:

v=spf1 include:_spf.google.com

(Google actually implements this as aspmx.googlemail.com which "redirects" to _spf.google.com, but I'm leaving out that indirection for simplicity's sake)

As a user of Zen broadband, we sometimes relay mail through mailhost.zen.co.uk despite the fact that we do have our own mail relay. It'd be useful if Zen would publish something like _spf.zen.co.uk containing a list of IP addresses for Zen's mail servers, which would then ultimately achieve the same goal as us obtaining a list of the current IP addresses from you but would allow you to update them in a centralized location whenever the IP addresses change.

As for SPF not preventing spam, I'm well aware of this. It's actually the preventing of the domain being spoofed that I'm interested in.

That is certainly a record I could look to add :-) I may not be willing to add SPF for the zen.co.uk domain itself but am happy to make our customers' lives easier in using it if they so wish. It won't however be an '_spf.zen.co.uk' record as '_' is technically an invalid character in DNS.

---

--
Jerry Nicholls
Principal Systems Engineer
perl -e '$_=q(print "perl -e \x27\$_=q($_);eval\x27\n");eval'

"_" is an invalid character in a hostname, but it's valid in DNS. I believe the initial underscore convention is intended to avoid collisions with valid hostnames. Notice that SRV records generally use an initial underscore to prevent collisions with hostnames, too.

With that said, the exact name of the record doesn't really matter as long as we all know what it is. I'd be really grateful if you could publish such a record.

Thanks.

Ok, I've added the TXT record for '_spf.zen.co.uk' that refers to our three smarthosts with a '?all' at the end. This may take a little while to propagate out fully however so I'd wait a wee while before referring to it. On the underscore note - I've had a read around and since it is explicitly within a suitable RFC I'll let the _spf record exist :-)

---

--
Jerry Nicholls
Principal Systems Engineer
perl -e '$_=q(print "perl -e \x27\$_=q($_);eval\x27\n");eval'

Great, thank you loads ! This is exactly what I was hoping for, will hopefully stop my From: being abused again (or at least increase the chances it'll be small scale), and once again shows how great Zen is.

Thanks for setting this up. Makes my life much easier!

Hi,

A really interesting thread. Could you tell me what SPF record I should add for my Zen hosted domain to allow messages to be sent only through my cPanel server or mailhost.zen.co.uk?

Thanks!

Tim

trwh:

Could you tell me what SPF record I should add for my Zen hosted domain to allow messages to be sent only through my cPanel server or mailhost.zen.co.uk?

Google will find you plenty of tools to help you create a SPF record, but an SPF record in DNS can not achieve what you think it can.

Hi,

Thanks for your reply, I'd like to know which servers I should mention in the SPF record, if I send via cPanel / mailhost, or which domain I should "include". For instance, I notice Zen don't appear to have an SPF record for zen.co.uk, is this correct?

trwh@vaglen:~$ nslookup -q=txt zen.co.uk
Server: 212.23.3.100
Address: 212.23.3.100#53

Non-authoritative answer:
zen.co.uk text = "Zen Internet Ltd, Rochdale, UK. Tel: +44 (0)870 6000 971"
zen.co.uk text = "To report abuse, contact: abuse@zen.co.uk"

Authoritative answers can be found from:
zen.co.uk nameserver = ns0.zen.co.uk.
zen.co.uk nameserver = ns1.zen.co.uk.
ns1.zen.co.uk internet address = 212.23.3.1
ns0.zen.co.uk internet address = 212.23.8.1

Thanks,

Tim