Talk:Sender Policy Framework

From Wikipedia, the free encyclopedia

Contents

[edit] Pre 2006 cleanup talk

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

[edit] Meng Weng Wong

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)

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

[edit] ID

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)

[edit] this needs correction

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)

[edit] dns records?

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)

[edit] BGP=?

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

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)


[edit] cleanup done

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)

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)

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

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.

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)

---

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)

---

"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)

[edit] DoS Attack

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

[edit] rvv 112 FUD

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

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

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)

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)

[edit] Answered questions

Apparently User:Elvey was banned for reasons unrelated to this article... :-| --217.184.142.58 (talk) 01:00, 2 June 2008 (UTC)

[edit] Incomprehensible

"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)

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)

[edit] Rejecting mail

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)

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)

[edit] Adoption

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)

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)

[edit] Some solved problems

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

[edit] Disambiguation

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)

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)

[edit] Testing page link seems 2B dead now

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)

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)

[edit] Garbled sentence

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)

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)