18 May
2005
18 May
'05
4:01 p.m.
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/
18 May
18 May
4:08 p.m.
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!
--
Andre
4:24 p.m.
On Wed, 2005-05-18 at 16:08 +0200, Andre Oppermann wrote:
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
Juerg Reimann wrote:
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.
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! 
4:29 p.m.
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
4:26 p.m.
New subject: IP 194.209.131.192 from swisscom in blacklists (blueberry service ?) ?
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(a)imp.ch> <mbr(a)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(a)freebsd.org>
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
------------------------------------------------------------------
5:14 p.m.
New subject: IP 194.209.131.192 from swisscom in blacklists (blueberry service ?) ?
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(a)imp.ch> <mbr(a)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(a)freebsd.org>
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
------------------------------------------------------------------
5:51 p.m.
New subject: IP 194.209.131.192 from swisscom in blacklists (blueberryservice ?) ?
Martin Blapp wrote:
Hi all,
Hmm... A rather expensive way of spamming... via Mobile. Fürst got
desperate?
--
Andre
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.
4:22 p.m.
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(a)lists.swinog.ch
[mailto:swinog-bounces@lists.swinog.ch]On Behalf Of Juerg Reimann
Sent: Wednesday, May 18, 2005 4:01 PM
To: swinog(a)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(a)lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
4:29 p.m.
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
--
HILOTEC Engineering + Consulting GmbH
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
19 May
19 May
10:37 a.m.
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(a)lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
--
_;\_ Philipp Morger / PHM2-RIPE System & Network Administrator
/_. \ Dolphins Network Systems AG Phone +41-1-847'45'45
|/ -\ .) Email: <philipp.morger(a)dolphins.ch>
-'^`- \; Don't send mail to: plonk(a)caretaker.dolphins.ch
20 May
20 May
11:10 a.m.
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
6584
days inactive
6586
days old
10 comments
7 participants
participants (7)
-
Andre Oppermann -
Jean-Pierre Schwickerath -
Jeroen Massar -
Juerg Reimann -
Martin Blapp -
Philipp Morger -
Steven Glogger