Page MenuHomePhabricator

[OPS] SPF (Sender Policy Framework) anti-forgery DNS record
Closed, ResolvedPublic

Description

Author: askoorb

Description:
Your domain does not have an SPF record. This means that spammers can easily
send out E-mail that looks like it came from your domain, which can make your
domain look bad (if the recipient thinks you really sent it), and can cost you
money (when people complain to you, rather than the spammer). 01 Oct 2004 was
the target date for domains to have SPF records in place (Hotmail, for example,
started checking SPF records on 01 Oct 2004).

There is even an Extention for Mozilla Thunderbird! (http://taubz.for.net/code/spf/)

For more info see http://spf.pobox.com/forsysadmins.html
and http://spf.pobox.com/

A Wizard to help is at http://spf.pobox.com/wizard.html

To give an example of how it works:

In this example, AOL.com is the sending domain, and pobox.com is the receiver.

AOL publishes an SPF record, specifying which computers on the Internet can send
mail as user@aol.com

  1. When a real AOL user sends mail, pobox.com receives the message from an AOL

server.

  1. Pobox checks AOL's SPF record, to make sure the server is allowed to send

mail from AOL.

  1. The server is listed, so Pobox gives the message a pass.

(Expensive content-based spam checks can be bypassed, saving resources on the
receiver side.) 1. When a spammer forges mail from AOL, Pobox receives the
messages from an outside server.

  1. Pobox checks AOL's SPF record.
  2. The server is not listed, so Pobox gives the message a fail.

(Expensive content-based spam checks can be bypassed, saving resources on the
receiver side.)

Have fun,

Alex


Version: unspecified
Severity: enhancement
URL: http://spf.pobox.com/

Details

Reference
bz1609
TitleReferenceAuthorSource BranchDest Branch
.gitlab/agents: Add allowed projectsrepos/qte/catalyst/catalyst-api!19jhuneidijhuneidi-main-patch-aa68main
Deploy to k8srepos/qte/catalyst/patchdemo!4jhuneidihelmmaster
Draft: Add publish steprepos/qte/catalyst/patchdemo!3jhuneidiT360912master
Add catalyst patchdemo to trusted runnersrepos/releng/gitlab-trusted-runner!67jhuneidiT360912main
Add initial CIrepos/commtech/wishlist-intake!2samtargitlab-cimain
Basic skeleton and Node setup for the Wishlist Intake formrepos/commtech/wishlist-intake!1musikanimalbootstrapmain
Ensure that error contents are included in logged string.repos/abstract-wiki/wikifunctions/function-orchestrator!151apineapine-fix-logmain
setup scriptsrepos/qte/catalyst/patchdemo!2jhuneidisetupmaster
Patchdemo initial versionrepos/releng/dev-images!64jhuneidipatchdemomain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 8:15 PM
bzimport added projects: DNS, acl*sre-team.
bzimport set Reference to bz1609.

rowan.collins wrote:

Just a note that some people consider SPF to be rather flawed, in that it breaks
a lot of expected behaviours in the e-mail system - for instance, a transparent
forwarding service will appear to be "spoofing" the address of all mail that
passes through it, unless it mangles the From addresses to declare itself as the
originating domain.

That said, it would obviously be useful to make it harder to spoof messages as
appearing to be from the Wikimedia Foundation [spam, arguably, has little to do
with it]. But this begs a number of questions, such as: Who (other than the
mailing list servers) actually sends mail from Wikimedia's domains? Do they
consistently do so by logging into Wikimedia's SMTP server (or are they
effectively "spoofing" the address themselves)? And is there really any risk
from other people spoofing those addresses?

askoorb wrote:

Thats a very good point, and yes, SPF is not perfect,

The only other similar service I know of is DomainKeys

http://antispam.yahoo.com/domainkeys
and
http://domainkeys.sourceforge.net/

But its a bit proprietary, and not the most widely adopted system.

SPF may be beneficial, but yes, could confuse some oddly configured (and
unfortunately not so oddly configured) external mail relay systems.

I was mainly suggestion it as a method to _stop_ people from 'spoofing' mail
from Wikipedia in the future, as this could become a bit of the problem if
Wikipedia's popularity continues to grow at its current rate

So far as I know, mail is handled exclusively by zwinger (have a lovely picture
of the server arrangements:
http://meta.wikimedia.org/wiki/Image:Wikimedia-servers-2005-01-30.png)

Thanks for the comment Rowan.

Not sure what the status on SPF, DomainKeys etc is. Fred, can you check up with Mark on currents status and see what we're most interested ins etting up?

mike.lifeguard+bugs wrote:

Note that OTRS does receive emails on a fairly regular basis asking us why we're spamming them. Our emails are being spoofed, so if there's a solution available it should perhaps be given a higher priority.

Giving half of Fred's old bugs to Ashar since I trust him to get it done or reassign if he doesn't have time.

Mark, can you have a look at setting SPF records in DNS?

I can not do anything for this bug since I have no ways to update DNS. I don't even know which servers send emails.

SPF records has been set for the wikimedia.org domain. Does not fix yet the project domains though.

Mail notifications are sent with wiki@wikimedia.org for origin. As I said previously, SPF records have been setup for wikimedia.org ( RT #362 ) which fix this bug.