Talk:Sender Policy Framework

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Pre 2006 cleanup talk[edit]

Please add any new issues at the end. Omniplex 05:13, 25 February 2006 (UTC)[reply]

Meng Weng Wong[edit]

The odd recent anon addition "Mang Wong who was maked" presumably relates to this Hungarian-language article. If someone can read Hungarian and write English, please fix the sentence to make sense (or eliminate if this is of no significance). -- Jmabel 20:39, 31 May 2004 (UTC)[reply]

I can't read Hungarian, but at least I know what Meng's name is; changed. Marnanel 21:48, 31 May 2004 (UTC)[reply]

ID[edit]

It would be very nice if your introduction to SPF explained how "receivers that implement SPF will know to ignore the message". If the SPF server publishes machine IDs what keeps the spammer from obtaining those IDs as an SPF client and abusing them?

Abusing them in what way? Marnanel 13:50, 18 Sep 2004 (UTC)
Apparently a confusion of ID and IP, should be clear now. Omniplex 05:13, 25 February 2006 (UTC)[reply]

this needs correction[edit]

SPF does *not* (by itself) validate From addresses -- not the ones you see in your e-mail messages. It validates the "mail from" header in the SMTP protocol itself, which isn't traditionally passed on to MUAs. Basically, the MTA needs to do the work (at least the initial work).

done Omniplex 04:57, 25 February 2006 (UTC)[reply]

dns records?[edit]

Aren't there dns records involved as well? 

Yes there are. SPF-record are entered as txt-record

Who's Steve Bellovin? Why should I care what he thinks about SPF? 

If you're a spammer, you should care, as he is making a statement to not believe the hype, and give spammers every chance to bore us with yet another useless viagra-pill.

Can anyone remove the controversy part? It is bogus, old and debunked.


RE: I also could not care less who Steve B. is, but I really want to know how to implement in Sendmail. "Sendmail" you know, the most used mailer in Internet, and NO SINGLE match in google on www.sendmail.org, WHY? —Preceding unsigned comment added by 84.61.92.62 (talk) 01:57, 3 November 2007 (UTC)[reply]

Sendmail cannot directly implement SPF because its ruleset language, M4, lacks the appropriate functional capability. However, there are many milters (add-ons) for Sendmail which can and/or do implement SPF. 2001:470:D:468:7455:7A:1C17:3DB4 (talk) 07:55, 19 November 2012 (UTC)[reply]


Correction: Aren't there dns records involved as well? 

Yes there are. SPF-record are entered as DNS SPF-RRs where supported, and TXT-RRs otherwise (deprecated).

RFC 4408 makes it clear that the use of TXT-RRs for SPF data was meant as a temporary measure until it received it's own resource record type, for which the IANA acted in 2006 by assigning type 99 to SPF-RRs. 71.106.210.230 (talk) 03:39, 1 November 2010 (UTC)[reply]

BGP=?[edit]

Say what BGP stands for. If giving a link, still say it too. 210.200.105.231 23:48, 9 February 2006 (UTC)[reply]

Removed, BGP is about routing IP packets, not about routing mail. SMTP is two protocol layers above IP (SMTP over TCP over IP). Omniplex 05:02, 25 February 2006 (UTC)[reply]

Depreciated --> Deprecated[edit]

I'm new here, so not sure if I need to bother explaining (or if this is the right place to do it) but I just changed the 'depreciated' in 'principles of operation' to 'deprecated'. Its a common mis-type, so presumably that's what the original author meant, but since the words actually have different meanings, I wanted to leave some clarification on my one-character-edit. Depreciation is the tendancy for assests to decline in value. Deprecation is a declaration that a previously favoured or standard practice is now discouraged. —Preceding unsigned comment added by Dufos (talk • contribs) 00:17, 24 December 2009 (UTC)[reply]

I can tell you it was NOT a typo. As the author, I wrote depreciated, as in to lessen in value over time. You should never presume over what someone else has written. 71.106.211.51 (talk) 00:20, 13 July 2011 (UTC)[reply]

cleanup done[edit]

This article had had a "cleanup" tag for over a year. Since the tag was added, the article has had scores of edits and been completely transformed. I don't know why no one removed the cleanup tag, but I did. Herostratus 08:21, 5 December 2005 (UTC)[reply]

In addition to this, I just fixed up a part where it said "major ISPs (MSN, Yahoo, AOL, etc.)" to "some major email service providers". This was to fix two problems: using "ISP" to denote these companies is misleading in the context of an email issue (One needn't be a MSN subscriber to have an MSN email), and, the fact that the paragraph goes on from there to list that both MSN and AOL have actually adopted forms of SPF. I have a feeling the information was simply dated, and no one wanted to fix the context.
in the common usage, "email service provider" often refers to entities that primarily send bulk mail, as opposed to those that send and receive balanced amounts mail. I'm not convinced that ESP is better than ISP. --Elvey 15:14, 31 March 2007 (UTC)[reply]

No honest criticism of SPF in the article.[edit]

It is a fact that vast majority of spam originates from malware-hijacked ("zombie") home user and corporate desktops, which have ample bandwidht via ADSL, CATV or leased line. Sorrowfully, SPF does not protect against this at all, because SPF makes the false assumption that spammers use their own systems to send junk mail. No, they do not, they use malware to hijack others' for this purpose.

In practice spammers are forced to rotate through a large number of sender addresses. This is because using the sender address of the owner of the compromised machine in conjunction with the smtp relay server allocated to that user doesn't work very well because the provider of the relay server quickly blocks that user. That provider doesn't want his relay server blacklisted (un-blacklisting incurs a fine) so he tends to be careful to monitor his users carefully. So the mailbot is forced to directly deliver email. Directly delivering mail without using a legitimite relay means being forced to use sender addresses that do not have SPF records. This is what happens in practice - well at least as was the state of spam in 2009-2010. —Preceding unsigned comment added by Paulsheer (talk • contribs) 14:34, 13 January 2010 (UTC)[reply]
In practice, spammers steal other people's email passwords, and then simply run the account into the ground and send a ton of spam with it. Sure the account gets nuked fairly quickly, but an initial large batch of spam still gets sent out. And if the account is one that's used to send out legitimate bulk email, so it can't be auto-disabled due to email frequency, it can and WILL be used to send out a truly frightening about of spam if it's password is guessed. Additionally it harms the reputation of the company who employs the person who's email got compromised. 2601:204:300:46C0:48F9:9FC8:2470:AB1B (talk) 01:00, 21 December 2023 (UTC)[reply]

Read this and be afraid, as this is almost as bad as Skynet:

Cryptographic SpamThru TrojanProxy Installs Own AV Scanner to Kill Competition

Therefore SPF is already useless and obsolete! Must write about it in the article. 195.70.32.136 13:36, 30 October 2006 (UTC)[reply]

I would like to see some backup for this fact. Not having seen any, I believe that a significant portion of spam does not come from hijacked computers.
But what does that have to do with SPF effectiveness? SFP helps me, the recipient, identify the sender. If mail is from a stranger, I can give it less respect than if it comes from someone I trust. I apply much more stringent spam filtering to mail from strangers. The hijacked computer almost certainly belongs to someone as strange to me as the spammer who hijacked it. Bryan Henderson 22:41, 25 February 2007 (UTC)[reply]

"SPF makes the false assumption that spammers use their own systems to send junk mail

SPF makes no such assumption. The point of SPF is not to stop spam, it is to positively identify legitimate mail, whether it is solicited or not. If SPF says the mail is from example.com, then the mail really is from example.com, whether it's spam or not. If you don't want mail from example.com, that's a different problem which SPF does not rectify.
The value of SPF is that spoofed mail can be rejected without even scanning the body. If example.com implements SPF and someone sends mail on behalf of example.com, there's no need to deliver the mail at all. It can be rejected immediately or silently dropped without repercussion. This protects example.com from spam delivered by bounce, and it protects example.com from accusations of spamming. Certainly example.com can send mail from hosts which are not theirs, but if they implement SPF they can have zero expectation of it being delivered to any recipients whose SMTP servers also implement SPF.
If example.com implements SPF and sends spam from their own servers, recipients have a means of fighting back with non-technical measures.
That is ALL that SPF offers, and it's a huge step forward over what we've got now. Crag 19:07, 1 June 2007 (UTC)[reply]


I added a link to an article with some criticisms of SPF, and a quick Google search found a number of others. However, what I really wanted to say is that while some domains are using SPF to delay or refuse mail, and a large number of domains are publishing some sort of SPF records (generally TXT, actual SPF DNS records are still pretty rare), SPF as a whole seems to be dead, because of its flaws and because so much old software would not be able to cope with it (MUAs, list software, etc.) I'm not sure how much verifiable evidence I'd have to drag up to publish something like that, though.

SPF doesn't do much to reduce general spam because most spammers these days are using throwaway or mismanaged domains, and because they can rely on people not to read the email headers anyway (i.e. the huge success of spearphishing, where people happily comply with a demand to mail their password, date of birth, and SSN to an ISP in China.)

SPF does a lot to prevent my email address from being used by spammers. And this is extremely useful to me. The purpose of SPF is not to identify or block spam. However, in practice it does help spam filters considerably because they have extra information by which to classify email.

Aliza250 (talk) 03:59, 17 December 2009 (UTC)[reply]

I believe that the introduction sentence is a bit misleading as it says that it's "designed to prevent e-mail spam". I would suggest that it is a tool used in helping with spam. At it's best, it resolves address spoofing - nothing more. It helps us validate that the e-mail is coming from who they say it is. However, as addressed by other editors, it does not give any confidence that the sending domain is someone you actually want mail from. SPF is a very fast filtering method, much faster then hieuristic type filtering. So we use it at the very front end to reject all e-mail that fails SPF. But an SPF pass does not give it a green light past the other SPAM filtering technologies we also use. One of the most notable changes I saw after widespread SPF adoption was that phishing e-mails no longer came from the actual company domain, but had to come from a different address. Tiggerjay (talk) 20:54, 13 January 2010 (UTC)[reply]

SPF does not prevent spoofing or forgery. It is typical for the email-addresses referencing SPF records to not be user visible, whether representing the return path or PRA. Even SPF records ending with "-all" seldom are refused because of the high associated path registration failure rates with this protocol. SPF was able to obtain rapid support from various sender organizations because it holds a different entity accountable and not those making a profit emitting questionable email in bulk. Even the Authentication-Results header for SPF fails to capture the only weakly authenticated identity within the exchange, the source IP address that might identify the bulk sender.

SPF was never intended as an "anti-spam" tool. Spam is a transmitter/recipient issue since spam is always defined as transmitting messages unwanted by recipients. Spam need not be forged. Forged messages need not be spam. It is also important to keep in mind that most consider the From header field to represent the originator of the message and will seldom even view the return path. Authenticating the MTA and assessing their reputation represents an effective method for dealing with spam. It would never be safe to impose reputations on domains that authorize shared MTAs so they will receive Non-Delivery Notifications. Few common providers will ensure their unique use of a return path. Doug.otis (talk) 23:02, 28 December 2011 (UTC)[reply]

DoS Attack[edit]

The link concerning DOS attacks of SPF (to the Internet Foundation) doesn't seem to work. I presume that it did indeed work at some point in history, but that the foundation has removed it (OR, that the intial user was mistaken in including the link). I'll wait a day, if no-one does anything about it, might as well remove the DOS attacks link.

KnasterTarski

The draft expired on December 26th. Doug Otis has not resubmitted it to the IETF. Wrs1864 13:14, 10 January 2007 (UTC)[reply]
Refactoring this (talk) page I moved an older complaint about DDoS FUD below as subsection. --217.184.142.58 (talk) 23:00, 1 June 2008 (UTC)[reply]

rvv 112 FUD[edit]

Crappy 112 lookups vandalism removed again, same procedure as in E-mail authentication and before in DomainKeys. Omniplex  10:21, 8 March 2006 (UTC)[reply]

While the DOS draft should have included explicit examples, this does not mean recipient resources can't be abused. Unfortunately, due to problems of blocked access leading to support calls, often recipients override SOA minimum field requested negative caching durations by imposing shorter maximum values.

Windows 2000 supports negative caching as specified in RFC2308, but with the modification of imposing low maximum limits. Negative responses are held for the number of seconds specified in the NegativeCacheTime value with a default limit of 300 seconds. The value of NegativeCacheTime can be set to 0. However, it can not be greater than 15 minutes. For Windows 2008, the dnscmd supports /maxnegativecachettl with a default of 10 minutes. Bind 8 and 9 also provide global max-ncache-ttl to limit negative caching. Cisco offers similar methods to limit negative caching using the command dns set max-negcache-ttl that defaults to 1 hour.

My involvement in the MARID WG dramatically reduced the potential number of DNS transactions permitted for SPF processing, with the exception of correcting the local-part macro issue. IMHO, only direct server authentication is practical and safe. With the introduction of NAT64 and other transport translation techniques, IP addresses as a basis to authorize a server no longer suits the Internet environment. Cryptographic methods are now urgently needed. Doug.otis (talk) 23:04, 28 December 2011 (UTC)[reply]

Will SPF Cause Spammers Not To Send Mail?[edit]

I deleted a sentence saying an advantage of SPF is that spammers won't send email with SPF-detectable spoofed origin because it would be wasteful, since the receiver would just delete it. I've seen no evidence that spammers go out of their way to avoid sending mail that will get deleted. The spam phenomenon is based on the fact that it costs roughly zero to send an email. If someone can provide evidence to the contrary, I would accept such a suggestion in the article. Bryan Henderson 22:25, 25 February 2007 (UTC)[reply]

YMMV, but I've seen some evidence in my inbox back in 2004, the difference between about 1000 bounces per day vs. none is quite notable with a V.90 account. Other folks also reported that "their" spammers (i.e. somebody forging their addresses) gave up some time after they published a FAIL policy. I've also heard two reliable reports where publishing a FAIL policy didn't help much so far, but one of these two reports is from a top anti-spammer worldwide, the spammers could deliberately ignore his FAIL policy. For the "day job" of a spammer, get unsolicited crap to unhappy receivers, forging FAIL protected addresses is just a bad idea, and spammers today are not as stupid as they used to be five years ago, they know this. --217.184.142.58 (talk) 23:57, 1 June 2008 (UTC)[reply]

Incomprehensible[edit]

"An SPF PASS result from unknown strangers still guarantees that auto-replies like error messages (bounces) cannot hit innocent bystanders." doesn't make sense. Removing as I can't figure out what the author(s) want to say, and some of the bit I understand appears to be incorrect. Some things that can be said: SPF doesn't prevent bounces to innocent bystanders; innocent bystanders with SPF records still receive bounces. If they know what IPs are legitimate sources for mail 'from' their domain, then they can filter the bounces they get, but with a significant, but often considered acceptable (about 1 in 20, in my experience) false positive rate. SPF is a handy way to obtain this list of IPs. When mail from innocent bystanders with SPF records bounces, the bounces generally don't have an SPF PASS result. Happy to see a replacement sentence reappear.--Elvey 16:26, 31 March 2007 (UTC)[reply]

Well, I tried to explain it again below where you or somebody else mentioned the idea to treat any PASS favorably, because that's beside the point. Look at it from a receiver's POV, you get tons and tons of mail, above 90% are spam. You have to decide to accept or reject mail fast, because (1) RFC 2821 won't let you take ages for this decision, it has a timeout of a few minutes, (2) senders might not give you the complete time for a decision permitted by RFC 2821, they could give up and try again later if you are too slow, (3) you have only mumble - say 40,000 - ports for simultaneous SMTP sessions. Therefore time-consuming spam checks in the SMTP session are an obstacle for professional e-mail service providers. If they accept the mail and it turns out to be suspicious and/or undeliverable later, they are in the known RFC 2821 dilemma, if it was legit they MUST send a bounce, but if it was spam the bounce is backscatter. After a PASS they can be sure that it is no backscatter. After a PASS they have as much time as they need to analyze attached pictures or other expensive checks, this could be on another box or by a third party. Even if it is spam they have a license to bounce, the PASS, and they are not tempted or forced to drop potentially legit mail. --217.184.142.58 (talk) 00:19, 2 June 2008 (UTC)[reply]


Rejecting mail[edit]

SPF does NOT explicitly RECOMMEND or REQUIRE message rejection, even on SPF FAIL. Instead, it says things like "In order to prevent the circumvention of SPF records, rejecting E-Mail from invalid domains should be considered." and "The checking software can choose to mark the mail based on this or to reject the mail outright." Perhaps it would be useful to address this and explain why it's the case.--Elvey 16:26, 31 March 2007 (UTC)[reply]

SPF explicitly RECOMMENDs an SMTP status code for receivers deciding to reject FAIL. For various reasons it does not say what receivers "should" decide, receivers are free to do what they like, the complete SPF design is intentionally voluntary. Clearly silently discarding FAIL would be a bad idea for the reasons mentioned in the article. So if receivers check SPF during SMTP as RECOMMENDed in the specification, and then don't reject FAIL, they are, hm, is mistaken the correct adjective when talking about Gmail? <gd&r> Seriously, it is possible to check SPF after SMTP, and at that point in time receivers can't reject a FAIL anymore. --217.184.142.58 (talk) 00:37, 2 June 2008 (UTC)[reply]
I see. I think you are incorrect; you assume spammers won't set up +all SPF records (or SPF records approving the hosts they decide to send spam from, e.g. their botnet or proxies). If they do, you can't assume that it's safe to bounce email sent that gets a PASS due to such a record. If the spammers control the SPF records, they control the MX records (presumably of a throwaway domain); they could point them at the servers of innocent bystanders. --Elvey (talk) 18:56, 18 November 2008 (UTC)[reply]


Should a pass that results due to the "+all" mechanism be handled differently than other passing declarations? I say yes, and I specifically check all passing records for the mechanism that triggered the determination. When I find that it was a "+all" (the plus sign being optional), I specifically reject any such attempted mail for local policy reasons (with extended code "5.7.9 Mechanism too weak"). To prevent spammers from constructing alternatives to "+all", one should also consider rejecting ALL matching CIDR-using mechanisms where the CIDR bitmask indicates fewer than 8 significant bits used in the address. There is no single (mailable) organization that controls any continuous address space of "*/7" or less, either in IPv4 or IPv6. 71.106.210.230 (talk) 21:38, 5 November 2010 (UTC)[reply]

Adoption[edit]

Adoption is more than just publishing SPF records. How 'bout a table: The rows would contain the largest senders and receivers, e.g. senderbase.org's Top Senders by Domain is a good start. Columns would include: Publishes SPF records for its domains. Treats SPF PASS significantly favorably. Rejects (or discards or shunts to a spam folder) on SPF FAIL. Complies with SRS. --Elvey 16:26, 31 March 2007 (UTC)[reply]

e.g.

Name Records. Treats SPF PASS favorably. Rejects on SPF FAIL. Complies with SRS.
tpnet.pl N ? ? ?
rr.com Y ? ? ?
rima-tde.net Y ? ? ?
yahoo.com N ? ? ?
verizon.net Y ? ? ?
comcast.net N ? ? ?
interbusiness.it N ? ? ?
wanadoo.fr N ? ? ?
t-dialin.net N ? ? ?
hinet.net ? ? ? ?
proxad.net ? ? ? ?
ttnet.net.tr ? ? ? ?
bezeqint.net ? ? ? ?
telesp.net.br ? ? ? ?
charter.com ? ? ? ?
163data.com.cn ? ? ? ?
veloxzone.com.br ? ? ? ?
cndata.com ? ? ? ?
t-ipconnect.de ? ? ? ?

From page 2, perhaps: arcor-ip.net ono.com hotmail.com tiscali.it net24.it mtu-net.ru brasiltelecom.net.br btcentralplus.com prod-infinitum.com.mx shawcable.net blueyonder.co.uk auna.net ntl.com qwest.net google.com netvision.net.il ocn.ne.jp asianet.co.th messagelabs.com aol.com, outblaze and other large receivers that don't send much bulk mail are needed too.

Getting reliable statistics or reliable info about SPF practises is hard for several reasons. E.g. Gmail does various things with SPF, but they don't reject FAIL, and they don't publish a FAIL policy. They check SPF (visible in Received-SPF headers) and they publish a PASS policy. GMX, a huge mail provider in Germany, rejects FAIL if users want this by enabling the corresponding option for their account. They publish a simple PASS or FAIL policy.
Treating PASS favorably is a bad idea, a PASS from unknown strangers means almost nothing, spammers are perfectly able to publish SPF policies for domains under their control. They can't publish policies for other domains, IOW they can't get a PASS for addresses in your or my domains (unless they actually send from our domains, if they turned some of our boxes into zombies). A PASS from unknown strangers is no waste of time, receivers can accept PASSing mail on probation. For a PASS they can send a bounce later without fearing to cause backscatter, or to drop legit mail. Even if the PASS was for spamming zombie in our domains, it's our job to fix it, we should get the bounce. --217.184.142.58 (talk) 23:39, 1 June 2008 (UTC)[reply]
I agree, and in my scoring system, pass gets 0, while neutral gets 1, none gets 2, and softfail gets 4 points (toward spaminess and/or lack-of-trust). An SPF hard failure and errors are rejected by the MTA at "MAIL FROM" and therefore never reach the scoring system, and neither does a pass which is "+all" or based on a CIDR mask of less than 8 significant bits, especially as spammers are likely to want to include the entire IP address space (either IPv4 or IPv6) as their authorized source. Although there is only one occurance of two consecutive IPv4 /8 assignments controlled by the same entity, those spaces do not form a /7. 71.106.211.51 (talk) 05:14, 13 August 2011 (UTC)[reply]

Some solved problems[edit]

Three minor solved problems collected in one section. --217.184.142.58 (talk) 23:39, 1 June 2008 (UTC)[reply]

Disambiguation[edit]

SPF shouldn't redirect here...I was looking for info on what it means in relation to suntan lotions 146.243.4.157 16:35, 13 June 2007 (UTC)[reply]

The disambiguation works as it should now, I hope you found the "sun protection factor" last year ;-) --217.184.142.58 (talk) 22:51, 1 June 2008 (UTC)[reply]

Testing page link seems 2B dead now[edit]

do they take money for that too now?

no, yo only mustn't press enter, but click with the mouse. Mifritscher (talk) 09:31, 21 December 2007 (UTC)[reply]

Whatever you're talking about, it sounds like you solved your problem. There are lots of testing pages, if something isn't as it should be report it to their webmasters, or if you want to discuss it here please add a link. --217.184.142.58 (talk) 23:11, 1 June 2008 (UTC)[reply]
I was considering reverting this: http://en.wikipedia.org/w/index.php?title=Sender_Policy_Framework&diff=next&oldid=252814931 but aside from the linkspam question, the myiptest tester DOESN'T WORK! It gives incorrect results.--Elvey (talk) 21:43, 3 December 2008 (UTC)[reply]

Garbled sentence[edit]

Under Mechanisms/EXISTS, is the following garbled sentence:

This is rarely used, along with the SPF macro language it offers more complex matches like DNSBL-queries.

Does anybody have any clue what this is supposed to be saying? One possible re-writing would be to turn it into:

This is rarely used. Along with the SPF macro language, it offers more complex matches like DNSBL-queries.

but I'm not sure that's the intent of what was originally written. -- RoySmith (talk) 16:59, 24 February 2008 (UTC)[reply]

Okay, done (disclosure: IIRC this was my fault). This is a Wiki, be bold and fix anything that's too far in the direction of a manual. --217.184.142.58 (talk) 22:37, 1 June 2008 (UTC)[reply]

Unexplained stuff[edit]

This is a very technical article. Even as a linux hobbyist for me it is very hard to read. In the Principles of Operation it is explained in very broad terms that it is a method of rejecting email based on the sender address. I would like more details on what is involved. How is it accomplished. Especially since just after that it suddenly becomes very technical and uses terms that haven't been explained previously. What is SPF PASS and SPF FAIL? "Spammers can send emails with SPF PASS result" - What does this mean? Why is it bad? "The main benefit of SPF.." - Potentially a good paragraph here, but the sentence "If such people use SPF to specify their legitimate sending IPs with a FAIL result for all other IPs" is not easy to understand. I guess it means that you can specify in the policy somehow to APPROVE these IP's and DENY all others, am I right? As a side note, an explanation of what is "The main benefit.." of this system should be further up on the page in my opinion. "SPF does not allow plain message forwarding." - What does this mean? And what does it mean to publish an SPF fail policy. A lot of terms again are used without explanation. Needs major cleanup work. Andersa (talk) 12:13, 6 November 2008 (UTC)[reply]

It is really challenging to explain while being precise and accurate without using something such as a definition section. Would that help?--Elvey (talk) 18:56, 18 November 2008 (UTC)[reply]
I'll put it simply: SPF is anti-forgery technology. Spam is a content issue. These are completely separate characteristics. Not all forgeries are spam. Not all spam are forgeries. Therefore, receiving spam with SPF status of "pass" means that one is certain that the origin (source IP address) was in fact under spammer control. 71.106.209.107 (talk) 00:44, 24 July 2009 (UTC)[reply]
Here is an analogy which may help. If I was to send you a regular physical letter through the post office, I would place a return address on it. Now in reality I could put whatever I want on there. I could put, President of the United States with a return address of the White House. The US Post Office will deliver the message, as they do not perform any sort of sender verification. This has been one of the problems with e-mail spam, people pretending that they're someone else -- such as your bank. With SPF, the administrators of the domain (such as @citibank.com) can specify exactly which servers on the internet should be permitted to send e-mail from @citibank.com. IF both Citibank and your e-mail provider was to implement SPF -- then you could be assured that e-mail which says it's coming from Citibank.com is really coming from them, and that someone else who is trying to pretend that they're from Citibank will have their e-mail rejected as SPAM. Now as the article goes into further detail, this is not the only source/reason for spam, but is only just one of them. Also, technically we're validating the MAIL FROM, instead of the FROM address you see in your mail program. But that's on a technical level. Tiggerjay (talk) 06:52, 6 September 2009 (UTC)[reply]
For what it's worth, I think the first section is it now stands is an excellent overview of what SPF is. To be fair, I know SMTP and related matters quite well, so it's hard for me to identify which phrasing may seem too technical to others. I'd like to thank the people who have worked on making it this useful. 66.16.55.157 (talk) —Preceding undated comment added 02:07, 20 November 2009 (UTC).[reply]

Shortcomings[edit]

Might be worth adding a section on the shortcomings of SPF. Controversy does already cover some of this, though.

1: The forwarding issue is the real killer. Business users expect to be able to forward messages. They do not expect to have to rewrite such messages from scratch. Yet, directly forwarded messages with unmodified headers will always fail SPF. Some mailservers claim to offer a fix for this, eg MDAemon, but when I tested such a proffered solution it just caused mail loops, and had to be turned off. Because of the forwarding issue, SPF is rarely used in hardfail mode.

2: SPF was introduced before the mobile computing boom, and has poor compatibility with situations where senders are typically forced to use a number of different smarthosts to send mail, according to which data carrier their mobile device is simlocked-to. For larger outfits running their own mailserver this can be worked-around by forcing all mail to go through the central server, but for smaller outfits with no central IT, the change of source IP address with carrier is a serious problem.

3: SPF is a domain-wide solution, and hence cannot be activated in hardfail mode for one user whose address is being forged by spammers, without also causing potential loss of valid messages from other users. --Anteaus (talk) 11:00, 11 June 2015 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to one external link on Sender Policy Framework. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 00:35, 7 January 2016 (UTC)[reply]

broken link[edit]

The link http://www.maawg.org/sites/maawg/files/news/MAAWG_Senders_BCP_Ver2a-updated.pdf in

"MAAWG Sender Best Communications Practices Executive Summary" (PDF). MAAWG. 2011-10-07. Retrieved 2012-04-27.

is broken, the document appears to have been replaced by https://www.m3aawg.org/sites/default/files/document/M3AAWG_Hosting_Abuse_BCPs-2015-03.pdf .

How to proceed?

Chaotix63 (talk) 15:15, 3 June 2016 (UTC)[reply]

re: broken link[edit]

I added a link to the revised "Best Common Practices" PDF, but did not remove the old broken one. And did not add the link you mention. Feel free to tidy up! cheers -- Rick Rleir (talk) 14:51, 1 September 2016 (UTC)[reply]

David Green[edit]

The article currently has "Dana Valerie Lank (née Green)", and formerly had "Dana Valerie Lank (previously D. Green)". But the sources have "David Green".

  1. Do we have any evidence that these names do refer to the same person?
  2. If they are the same person, are we being overly sensitive about the change from a seemingly masculine name to a seemingly feminine one? (I say "seemingly", because I've been caught out by French names before: "Jean Marie" seems feminine to an Anglophone ... oops)
  3. The construction "Dana Valerie Lank (née Green)" indicates a previous name "Dana Valerie Green", which also doesn't match the sources. Perhaps the name has changed twice, from David Green to Dana Valerie Green to Dana Valerie Lank?

I would like to propose some wording that doesn't make the reader go "WTH?". We could use "Dana Valerie Lank (writing as David Green)". It was good enough for George Eliot.

This isn't a biography; for the purposes of attribution we don't need to wonder why a person goes by two different names.

Pelagic (talk) 21:31, 26 May 2016 (UTC)[reply]

I transitioned MtF around 2011[1], changing my name from David to Dana. I am thankful that you are using "née Green", and omitting my given first name. I only wish the spec could be changed, but that's life I guess. My current name is Dana Valerie Reese.[2]

DanaValerie (talk) 20:57, 9 July 2017 (UTC)[reply]

References

  1. ^ https://drive.google.com/file/d/0B3XZNMBzUgqHSzBRNFItd3pOQ0E/view?usp=sharing
  2. ^ https://drive.google.com/file/d/0B3XZNMBzUgqHNTdxZXFQdTlyVXM/view?usp=sharing

"&spf=" url parameter[edit]

There seems to be a completely unrelated computer usage of "spf". Google is currently tacking on "&spf=" parameters to search urls. Please add a link from this article to some info about this other usage of the term.-71.174.186.57 (talk) 17:42, 11 July 2017 (UTC)[reply]

Naming: should conform with DMARC and DKIM[edit]

We should pick one "standard" and stick with it. — Preceding unsigned comment added by 195.67.91.199 (talk) 11:34, 25 November 2021 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Sender_Policy_Framework&oldid=1203746927"