[Wylug-discuss] SPF records

[Chris Davies]

Nigel Metheringham wrote:
>Its also been interesting watching large providers back away from SPF -
>a number of major providers no longer publish SPF records, and others
>have changed their records to make them effectively advisory

Wasn't aware of that; I've only been seeing it grow. The mail system needs to be 
completely overhauled if we (the Internet "community") are really going to make 
any progress, and that is not going to happen any time soon. I certainly don't 
like DJB's alternative (at http://cryp.to IIRC). At least SPF only breaks 
forwarding - and I don't have a major problem with the rewriting of envelopes to 
resolve that.

James, I notice that you publish SPF on your domain, so I was able to see that 
it was /likely/ that your email came from there. In case anyone's interested, 
I'm using the SPF extension for Thunderbird.


Nigel:
>In fact SPF is best considered as an additional input
>to a scoring system like that operated by SpamAssassin and is not safe
>to reject mail on alone.

That's probably how I would implement it on inbound traffic, but for now I'm 
really interested in how to resolve enough issues to be able to publish an SPF 
record for others to use.


Chris (me):
>We have a number of laptop users who can connect back to our LAN/WAN using VPN. 
>For us, there is nothing that stops these users from sending emails from their 
>work email address while *disconnected* from the VPN

Nigel:
>Allowing company email to bypass company systems is a dangerous
>precedent.

Not my rules, but it's what we're now stuck with.

James Holden wrote:
> if you put in place policies that acknowledge that this may happen, you
 > can mitigate the effects to some extent.

That people might - but should not - send email without being connected to the 
company LAN? I don't see that this usefully resolves anything. You then have a 
means to slap someone's wrist for breaking the policy, but IMO this is one of 
the situations where a written policy needs to be backed up with a technical 
solution.


Nigel:
>The answer to this is to enforce company email passing through your mail
>servers.  You should do this by having a SMTP server available to those
>outside the network accepting email on the MSA port (port 587 - Mail
>Submission), which should be SMTP/TLS with enforced authentication.

I'll take a look at MSA. In order to make life easy for the laptop users, I 
guess I'd need something similar on the inside of our network, too.


James:
> In terms of policy, it's difficult to enforce. Anyone can spoof anyone's
> mail, it's inherently open to abuse.

Which is what SPF attempts to mitigate. It's not an anti-spam solution, but if I 
can help someone determine whether it's /likely/ an email really did come from 
me I'd appreciate it. For important stuff I often apply an S/MIME certificate to 
my email, but for many people at work a mail gateway adds a disclaimer to all 
outbound emails. (Please don't comment on the stupidity or otherwise of adding 
disclaimers. I've read the arguments.)


James:
> Getting a little more creative, you might also consider having your
> 'real' outbound mail server add some sort of signature to the email. By
> this I mean a digital signature on the message content.

Like DomainKeys?


James:
> Adding this signature would lend weight to any company policy by
> allowing the assertion that the company will not stand by the
> authenticity of any message not bearing the signature.

But surely this is what SPF attempts to achieve, but by different means. My mail 
system can look up the SPF record for a domain and decide whether it's more or 
less likely to be a legitimate email. I can then add that into my existing 
SpamAssassin scoring to determine how to process the message.

Thanks,
Chris
-- 
Chris Davies MBCS, chris.davies at bcs.org.uk, 07778 199069