To whom it may concern...
I've run a little test whether Swiss ISPs use SPF or not and it turned out that very few have actually implemented it (actually, I found not a single one). Is there a reason for that? It's a very simple implementation and it could prevent a lot of damage like the most recent one after Sober.Q.
I would suggest ISPs should implement SPF quickly and talk to their customers about it. (See http://spf.pobox.com/ for further information.)
Regards, Juerg Reimann
Juerg Reimann wrote:
To whom it may concern...
I've run a little test whether Swiss ISPs use SPF or not and it turned out that very few have actually implemented it (actually, I found not a single one). Is there a reason for that? It's a very simple implementation and it could prevent a lot of damage like the most recent one after Sober.Q.
SPF is broken by design.
I would suggest ISPs should implement SPF quickly and talk to their customers about it. (See http://spf.pobox.com/ for further information.)
How about you start with your domain and your users first and then report back how it went and what problems you encountered? Lead us the way!
On Wed, 2005-05-18 at 16:08 +0200, Andre Oppermann wrote:
Juerg Reimann wrote:
To whom it may concern...
I've run a little test whether Swiss ISPs use SPF or not and it turned out that very few have actually implemented it (actually, I found not a single one). Is there a reason for that? It's a very simple implementation and it could prevent a lot of damage like the most recent one after Sober.Q.
SPF is broken by design.
URL/ref/explaination/fulltext/elaborate?
It indeed does not stop spam, it does (partially) stop faking your source email domain, which could partially stop virus spreads, but that would require that a large (>75%) of the global is using it. No check somewhere -> does not work.
I personally would like to see every SMTP box checking that mails are signed per PGP, but that implies other problems too I guess... deployment is the first thing and that other thing called PKI seems to be a long long way on the road to oblivion too.
I would suggest ISPs should implement SPF quickly and talk to their customers about it. (See http://spf.pobox.com/ for further information.)
How about you start with your domain and your users first and then report back how it went and what problems you encountered? Lead us the way!
Well, there is a SPFv1 record on his domain: jworld.ch TXT "v=spf1 ip4:66.150.163.128/26 ip4:82.195.224.240 ~all"
But that ends in a ~all, thus basically the last Sober.Q runs (I assume he means that german propaganda crap of the last couple of days) would not have been 'stopped' because of the above. The "~all" would simply mean a softfail, thus the box will accept it, though maybe some spamcheck engine might choose to add some points to the spamscore because of it.
The point why I don't have SPF stuff on my domains is simple: IPv6 is not supported well enough, read: it is defined ambiguously and most likely the few boxes that have SPF checking installed won't understand the ip6 directive, thus when sending mail from a domain with the ip6 directive and -all, mail is most likely to end up in nothingness, which is not what one wants, and ~all is simply not adequate.
If the above concern would be gone, which will take quite some time, I might add it, as it would save getting my addy used to spam a large number of the ISP's who do check it. Getting those bounces is just a bit annoying even if they end up in the spam folder.
Greets, Jeroen
It indeed does not stop spam, it does (partially) stop faking your source email domain, which could partially stop virus spreads, but that would require that a large (>75%) of the global is using it. No check somewhere -> does not work.
SPF will only work for scoring, but not for rejecting e-mails.
it's like IPv6 - you cannot expect the whole internet and all domain admins to really put SPF in place - so you'll have around 15% of domains which are using SPF and the rest is not using it or even aware of it (implify everywhere ~all).
-steven
The IP 194.209.131.192 seems to be from the swisscom-mobile block 194.209.131.192 - 194.209.131.223. And it seems this server is listed in two blacklists.
RCVD_IN_SORBS_WEB RBL: SORBS: sender is a abuseable web server\n\t [194.209.131.192 listed in dnsbl.sorbs.net]\n\t RCVD_IN_CBL_SPAM RBL: Listed in cbl.abuseat.org\n\t [194.209.131.192 listed in cbl.abuseat.org]\n\t
This is causing trouble for customers of ours (and swisscom).
Martin
Martin Blapp, mb@imp.ch mbr@FreeBSD.org ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: <finger -l mbr@freebsd.org> PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------
Hi all,
The IP 194.209.131.192 seems to be from the swisscom-mobile block 194.209.131.192 - 194.209.131.223. And it seems this server is listed in two blacklists.
Looks like this is swisscoms wireless service.
And they are also listed in spamhaus.org.
Martin Blapp, mb@imp.ch mbr@FreeBSD.org ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: <finger -l mbr@freebsd.org> PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------
Martin Blapp wrote:
Hi all,
The IP 194.209.131.192 seems to be from the swisscom-mobile block 194.209.131.192 - 194.209.131.223. And it seems this server is listed in two blacklists.
Looks like this is swisscoms wireless service.
And they are also listed in spamhaus.org.
Hmm... A rather expensive way of spamming... via Mobile. Fürst got desperate?
hi juerg
sorry to say, but it seems you don't know all the advantages/disadvantages of SPF. SPF validates the domain of the mail envelope "return-path". this will lead spammers to use on-time-domains (register skdlfjasldfj24829402.com for that) ;-)
at the moment you can only use SPF to verificate, that this user is really allowed to send email/spam/whatever and therefore you just say: ok, it's not spam. so, just use SPF as a additional criteria to your probably spamassassin based spam filter, or do you really deny mails on SPF values?
another problem are relayed domains or domains, which are forwarded. the SPF entry will be false for that one.
then, how do you solve customers, which use abroad email servers to send their emails? (e.g. customer in germany, uses t-online.de mailerver and yes, i know that ther is a solution called SMTP AUTH - tell this to the customer ,-)) and i'm sure you can fake the headers that you will not use SPF to validate those headers.
so, in conclusion it's just a thing that takes the spammer some weeks/days/hours to implement a new solution and start again throwing tons of mails out to the big dark space called internet ;-)
just my 2 cents
-steven
oh, at least you implemented it ;-)
-su-2.05b# host -t TXT jworld.ch jworld.ch descriptive text "v=spf1 ip4:66.150.163.128/26 ip4:82.195.224.240 ~all"
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch]On Behalf Of Juerg Reimann Sent: Wednesday, May 18, 2005 4:01 PM To: swinog@swinog.ch Subject: [swinog] SPF implementation
To whom it may concern...
I've run a little test whether Swiss ISPs use SPF or not and it turned out that very few have actually implemented it (actually, I found not a single one). Is there a reason for that? It's a very simple implementation and it could prevent a lot of damage like the most recent one after Sober.Q.
I would suggest ISPs should implement SPF quickly and talk to their customers about it. (See http://spf.pobox.com/ for further information.)
Regards, Juerg Reimann
-- jradio.ch St. Jakobstrasse 39 CH-8004 Zürich +41 43 544 07 70
business card: http://jradio.ch/contact/ security keys: http://jradio.ch/pubkeys/
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi Juerg,
I've run a little test whether Swiss ISPs use SPF or not and it turned out that very few have actually implemented it (actually, I found not a single one). Is there a reason for that? It's a very simple implementation and it could prevent a lot of damage like the most recent one after Sober.Q.
Well, we do. We are not quite an ISP, but for most of the domains we host, we have started to apply SPF.
Actually, I know that ip-plus has SPF-rules (restrictive) and solnet also does (allow all).
I would suggest ISPs should implement SPF quickly and talk to their customers about it. (See http://spf.pobox.com/ for further information.)
Most of our users have been "victims" in the past of forged from addresses and did indeed understand when we proposed to use SPF. The problem is that if big ISPs like bluewin (where most forged mails come from - at least for us) don't implement it, it's hard to catch the fraud.
Regards,
Jean-Pierre
An F for effort... ;)
--($:~)-- dig newsletter.sunrise.ch TXT +short "spf2.0/pra ip4:146.82.220.0/23 ip4:198.31.62.0/23 ip4:209.47.11.0/24 ip4:62.221.20.0/24 ip4:65.167.67.192/27 ip4:216.73.80.0/20 ~all" "v=spf1 ip4:146.82.220.0/23 ip4:198.31.62.0/23 ip4:209.47.11.0/24 ip4:62.221.20.0/24 ip4:65.167.67.192/27 ip4:216.73.80.0/20 ~all"
On Mit, Mai 18, 2005 at 16:01:13 +0200, Juerg Reimann wrote:
To whom it may concern...
I've run a little test whether Swiss ISPs use SPF or not and it turned out that very few have actually implemented it (actually, I found not a single one). Is there a reason for that? It's a very simple implementation and it could prevent a lot of damage like the most recent one after Sober.Q.
I would suggest ISPs should implement SPF quickly and talk to their customers about it. (See http://spf.pobox.com/ for further information.)
Regards, Juerg Reimann
-- jradio.ch St. Jakobstrasse 39 CH-8004 Zürich +41 43 544 07 70
business card: http://jradio.ch/contact/ security keys: http://jradio.ch/pubkeys/
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
On Thu, 2005-05-19 at 10:37 +0200, Philipp Morger wrote:
An F for effort... ;)
--($:~)-- dig newsletter.sunrise.ch TXT +short "spf2.0/pra ip4:146.82.220.0/23 ip4:198.31.62.0/23 ip4:209.47.11.0/24 ip4:62.221.20.0/24 ip4:65.167.67.192/27 ip4:216.73.80.0/20 ~all" "v=spf1 ip4:146.82.220.0/23 ip4:198.31.62.0/23 ip4:209.47.11.0/24 ip4:62.221.20.0/24 ip4:65.167.67.192/27 ip4:216.73.80.0/20 ~all"
Indeed the larger "Advertisers" have already embraced this great technology called SPF so that they won't be filtered:
inetnum: 62.221.20.0 - 62.221.20.255 netname: DOUBLECLICK-IE descr: Double Click, Ireland
Double Click DOUBLECLICK7-62-28 (NET-198-31-62-0-1) 198.31.62.0 - 198.31.63.255 Double Click MEDSYN7-UUU1 (NET-209-47-11-0-1) 209.47.11.0 - 209.47.11.255 Double Click FON-110147993679739 (NET-65-167-64-0-1) 65.167.64.0 - 65.167.67.255 NetRange: 216.73.80.0 - 216.73.95.255 CIDR: 216.73.80.0/20 NetName: DOUBLECLICK-NET
network:ID:4632.146.82.220.0/23 network:Auth-Area:net.146.82.0.0-16 network:Network-Name:1682.1682.DOCLI
This thus only 'protects' nobody sending a faked newsletter (read: advertisement) mails from doublyclick... very useful.
Greets, Jeroen
-
Andre Oppermann -
Jean-Pierre Schwickerath -
Jeroen Massar -
Juerg Reimann -
Martin Blapp -
Philipp Morger -
Steven Glogger