Talk:Sender Policy Framework

message: Please add any new issues at the end. Omniplex 05:13, 25 February 2006 (UTC)
replies: text: I can't read Hungarian, but at least I know what Meng's name is; changed. Marnanel 21:48, 31 May 2004 (UTC)

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

text: done Omniplex 04:57, 25 February 2006 (UTC)

text: 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)

text: 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)
thread_title:  Pre 2006 cleanup talk 

message: 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)
replies: text: I can't read Hungarian, but at least I know what Meng's name is; changed. Marnanel 21:48, 31 May 2004 (UTC)
thread_title:  [[Meng Weng Wong]] 

message: 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)
replies: text:  Apparently a confusion of ID and IP, should be clear now. Omniplex 05:13, 25 February 2006 (UTC)
thread_title:  ID 

message: 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)
thread_title:  this needs correction 

message: 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)
replies: text: 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)
thread_title:  dns records? 

message: Say what BGP stands for. If giving a link, still say it too. 210.200.105.231 23:48, 9 February 2006 (UTC)
replies: text: 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)
thread_title:  BGP=? 

message: 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)
thread_title:  Depreciated --> Deprecated 

message: 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)
replies: text: 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)
thread_title: DoS Attack 

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

message: "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)
replies: text: 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)
thread_title: Incomprehensible

message: 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)
replies: text: 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)
replies: text: 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)
thread_title: Rejecting mail

message: Three minor solved problems collected in one section. --217.184.142.58 (talk) 23:39, 1 June 2008 (UTC)
replies: text: 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)

text: 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)
replies: text: 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)

text: 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)
thread_title:  Some solved problems 

message: 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)
replies: text: 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)
thread_title:  Disambiguation 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Testing page link seems 2B dead now 

message: Under Mechanisms/EXISTS, is the following garbled sentence:
Does anybody have any clue what this is supposed to be saying?  One possible re-writing would be to turn it into:
but I'm not sure that's the intent of what was originally written.  -- RoySmith (talk) 16:59, 24 February 2008 (UTC)
replies: text: 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)
thread_title:  Garbled sentence 

message: 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)
replies: text: 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)
replies: text: 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)

text: 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)

text: 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)
thread_title:  Unexplained stuff 

message: 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)
thread_title:  Shortcomings 

message: Hello fellow Wikipedians,
I have just added archive links to  on Sender Policy Framework. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive https://web.archive.org/20100129195805/http://www.emailmanual.co.uk:80/index.php/2009/05/why-should-i-implement-a-spf-record-on-my-domain to http://www.emailmanual.co.uk/index.php/2009/05/why-should-i-implement-a-spf-record-on-my-domain/
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
Cheers.—cyberbot IITalk to my owner:Online 00:35, 7 January 2016 (UTC)
thread_title:  External links modified 

message: The link http://www.maawg.org/sites/maawg/files/news/MAAWG_Senders_BCP_Ver2a-updated.pdf in
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)
thread_title:  broken link 

message: 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)
thread_title:  re: broken link 

message: 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".  
# Do we have any evidence that these names do refer to the same person? 
# 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)
# 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)
thread_title:  David Green 

message: 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)
thread_title:  "&spf=" url parameter 

message: * The SPF page is called: "Sender Policy Framework" (https://en.wikipedia.org/wiki/Sender_Policy_Framework)
* The DKIM page is called: "DomainKeys Identified Mail" (https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail)
* The DMARC page is called: "DMARC" (https://en.wikipedia.org/wiki/DMARC)
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)
thread_title:  Naming: should conform with DMARC and DKIM