Re: [swinog] Swisscom IPv6 Routing weirdness

[Jean-Pierre Schwickerath]

Dear all

On 09.03.21 11:16, Jeroen Massar wrote:
> I have your answer :)
>
> $ telnet -6 www.swisscom.ch 80
> Trying 2a02:a90:c400:5001::2...
> telnet: Unable to connect to remote host: Connection refused

I have an update on this issue. I was so blunt and opened a ticket for
an IP-Plus customer, claiming that they could not access www.swisscom.ch
over IPv6.

It took some time and at least three second-level supporters until
someone within IP-Plus found someone from the webserver team who knew
who was managing that load-balancer and now IPv6 seems to work again. I
have yet to receive an official confirmation that the issue is
permanently solved. Maybe they'll share the root cause of the issue but
I doubt it.

Best Regards and thank again to all who gave insights into those
technical details within tcpdump.

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - https://www.hilotec.com/



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom IPv6 Routing weirdness

[Jean-Pierre Schwickerath]

Hi Gregor

Thank you for your insights.

On 02.03.21 20:51, Gregor Riepl wrote:
> I tried different ISPs to which I have access and I can't establish a
> IPv6 connection to port TCP/443 to neither 2a02:a90:c400:4001::2 nor
> 2a02:a90:c400:5001::2 which seems the two loadbalancers responsible for
> www.swisscom.ch except from a Swisscom Business DSL connection.
>
> Init7 -> fail
> Strange, from AS13030 (Fiber7 residential), both IPs work fine.
I just tried it again from a customer with a Fiber7 access and I still
can't open www.swisscom.ch neither in a browser edge / firefox on a
windows machine, nor from wget on a linux server.


> Perhaps something is wrong with your test client? Wrong MTU? OS issue?
> Did you try a different machine?

I tried from various windows and linux machines from our office (via
netrics), from customers (fiber7) and from our datacenter (nts) and it's
all the same - I use different routers, different OS versions.

My datacenter ISP (nts) suspects that it's a reverse path issue and
advised me to use atlas probes to confirm.

I made two mesurement but the results show more successes that failure:

https://atlas.ripe.net/measurements/29275604/#probes

https://atlas.ripe.net/measurements/29275617/#probes


So maybe it's really only me and I have to live with the fact that I
can't login to the swisscom website when v6 connectivity is enabled.

Strange thing is that I even found a swisscom sme fiber customer where
the connection to https://www.swisscom.ch times out and one on a ip-plus
fiber access. Maybe that's my best bet to open a ticket with their support.

It would be so much easier to debug if their webserver would answer to
pings on v6.

I'll keep the list updated if I have any relevant news.


Best Regards and thanks again to all of you who spend some time on this
issue already

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - https://www.hilotec.com/



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom IPv6 Routing weirdness

[Jean-Pierre Schwickerath]

Hi Jeroen

There were two issues, one has been resolved, which was the routing
issue I was seeing from one of the networks where I tested from.

What remains is that I can't open a successful TCP connection to
www.swisscom.ch on Port 443 when coming from a non-swisscom network.

> Check with a tcpdump, don't forget to include ICMP.
>
> Could also be an MTU issue or something on your side killing it.
>
> Of course the behavior of the "load balancer" says quite a few things... 
> sbb.ch is like that too...
>
I tried different ISPs to which I have access and I can't establish a
IPv6 connection to port TCP/443 to neither 2a02:a90:c400:4001::2 nor
2a02:a90:c400:5001::2 which seems the two loadbalancers responsible for
www.swisscom.ch except from a Swisscom Business DSL connection.

Init7 -> fail

UPC Business -> fail

Tineo/Netrics -> fail

NTS -> fail

TCP dump looks like that

tcpdump -v -ni eth1 host 2a02:a90:c400:4001::2
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
262144 bytes
08:19:41.525301 IP6 (hlim 64, next-header TCP (6) payload length: 40)
2a00:c38:102::194.39622 > 2a02:a90:c400:4001::2.443: Flags [S], cksum
0x7192 (incorrect -> 0xdf6f), seq 788917482, win 28800, options [mss
1440,sackOK,TS val 2090291639 ecr 0,nop,wscale 7], length 0
08:19:42.522914 IP6 (hlim 64, next-header TCP (6) payload length: 40)
2a00:c38:102::194.39622 > 2a02:a90:c400:4001::2.443: Flags [S], cksum
0x7192 (incorrect -> 0xde75), seq 788917482, win 28800, options [mss
1440,sackOK,TS val 2090291889 ecr 0,nop,wscale 7], length 0
08:19:44.526884 IP6 (hlim 64, next-header TCP (6) payload length: 40)
2a00:c38:102::194.39622 > 2a02:a90:c400:4001::2.443: Flags [S], cksum
0x7192 (incorrect -> 0xdc80), seq 788917482, win 28800, options [mss
1440,sackOK,TS val 2090292390 ecr 0,nop,wscale 7], length 0
08:19:48.534889 IP6 (hlim 64, next-header TCP (6) payload length: 40)
2a00:c38:102::194.39622 > 2a02:a90:c400:4001::2.443: Flags [S], cksum
0x7192 (incorrect -> 0xd896), seq 788917482, win 28800, options [mss
1440,sackOK,TS val 2090293392 ecr 0,nop,wscale 7], length 0
08:19:53.528648 IP6 (hlim 51, next-header TCP (6) payload length: 20)
2a02:a90:c400:4001::2.443 > 2a00:c38:102::194.39622: Flags [R.], cksum
0x85fa (correct), seq 0, ack 788917483, win 0, length 0

Sometimes, if I try hard enough I get a TCP connection and something
like a TLS1.3 session but no successul TLS negociation (neither with
wget nor with openssl s_client): then it looks like that:

08:27:26.984895 IP6 (flowlabel 0x76030, hlim 64, next-header TCP (6)
payload length: 20) 2a02:a90:c400:4001::2.443 >
2001:1a88:2200:505::6.53984: Flags [R.], cksum 0xcb4a (correct), seq
448778729, ack 2002587856, win 234, length 0
08:27:32.727483 IP6 (flowlabel 0x90338, hlim 64, next-header TCP (6)
payload length: 40) 2001:1a88:2200:505::6.53988 >
2a02:a90:c400:4001::2.443: Flags [S], cksum 0x9a58 (incorrect ->
0x3075), seq 3336725868, win 64800, options [mss 1440,sackOK,TS val
1531978773 ecr 0,nop,wscale 7], length 0
08:27:32.727864 IP6 (flowlabel 0x53256, hlim 64, next-header TCP (6)
payload length: 32) 2a02:a90:c400:4001::2.443 >
2001:1a88:2200:505::6.53988: Flags [S.], cksum 0x6587 (correct), seq
83163391, ack 3336725869, win 28800, options [mss
1440,nop,nop,sackOK,nop,wscale 7], length 0
08:27:32.727910 IP6 (flowlabel 0x90338, hlim 64, next-header TCP (6)
payload length: 20) 2001:1a88:2200:505::6.53988 >
2a02:a90:c400:4001::2.443: Flags [.], cksum 0x9a44 (incorrect ->
0x14cb), seq 1, ack 1, win 507, length 0
08:27:32.728373 IP6 (flowlabel 0x90338, hlim 64, next-header TCP (6)
payload length: 337) 2001:1a88:2200:505::6.53988 >
2a02:a90:c400:4001::2.443: Flags [P.], cksum 0x9b81 (incorrect ->
0x4bc2), seq 1:318, ack 1, win 507, length 317
08:27:32.728556 IP6 (flowlabel 0x53256, hlim 64, next-header TCP (6)
payload length: 20) 2a02:a90:c400:4001::2.443 >
2001:1a88:2200:505::6.53988: Flags [.], cksum 0x149f (correct), seq 1,
ack 318, win 234, length 0
08:27:44.732866 IP6 (flowlabel 0x53256, hlim 64, next-header TCP (6)
payload length: 20) 2a02:a90:c400:4001::2.443 >
2001:1a88:2200:505::6.53988: Flags [R.], cksum 0x149b (correct), seq 1,
ack 318, win 234, length 0

I'm by no means a tcpdump expert:

Those incorrect checksums: are my systems generating incorrect checksums
or is it the swisscom side? It seems weird that different systems with
different OS at different customers would all start making wrong tcp
checksums.


Best Regards

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - https://www.hilotec.com/



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Swisscom IPv6 Routing weirdness

[Jean-Pierre Schwickerath]

Dear Swisscom Routing-Experts

Are you not peeing at swissIX anymore?

Your webserver www.swisscom.ch (2a02:a90:c400:4001::2) gives me a hard
time to be reached. Either it wants it traffic to be routed from Berne
via NL, UK, US and ends in a sinkhole or it uses what looks like using
private peering from tineo/netrics/finecom to the same sinkhole:


tracepath6 2a02:a90:c400:4001::2
 1?: [LOCALHOST]    0.367ms pmtu 1500
 1:  sv96.hilotec.net  0.776ms
 1:  sv96.hilotec.net  0.740ms
 2:  2a00:c38::1:0:2a  1.538ms
 3:  lo0.01.p.cbn.ch.as15576.nts.ch    1.725ms
 4:  lo0.01.p.czh.ch.as15576.nts.ch    4.075ms
 5:  lo0.02.p.czh.ch.as15576.nts.ch    4.354ms
 6:  zayog.swissix.ch 10.184ms
 7:  no reply
 8:  ae2.cs1.ams17.nl.eth.zayo.com   151.857ms asymm 25
 9:  no reply
10:  no reply
11:  no reply
12:  ae5.cs1.lhr11.uk.eth.zayo.com   153.354ms asymm 21
13:  no reply
14:  2001:438:::407d:1d13    151.202ms asymm 19
15:  ae6.cs1.sjc2.us.eth.zayo.com    159.227ms asymm 18
16:  ae9.mpr1.pao1.us.zip.zayo.com   152.345ms
17:  2001:438:fffe::2456 153.873ms asymm 10
18:  2001:c10:80:1::e51  259.737ms asymm 10
19:  2001:c10:80:1::b96  265.511ms asymm 11
20:  2001:c10:80:2::ad2  243.109ms asymm 10
21:  geb-030-lo0-0.ip6.ip-plus.net   247.019ms asymm  9
22:  geb-015-loo6.ip6.ip-plus.net    236.957ms asymm  8
23:  gem-005-loo6.ip6.ip-plus.net    242.943ms asymm  8
24:  2001:918:100:63::1  230.491ms asymm  7
25:  2001:918:100:4c::1  240.121ms asymm  8
26:  2001:918:100:52::1  247.741ms asymm  7
27:  2001:918:ce::49 241.013ms asymm  8
28:  2a02:a90:4024:fff::14   247.804ms asymm  9
29:  2a02:a90:4024:fff::15   234.473ms asymm  8
30:  no reply
 Too many hops: pmtu 1500
 Resume: pmtu 1500


tracepath 2a02:a90:c400:4001::2
 1?: [LOCALHOST]    0.030ms pmtu 1500
 1:  router.3550.ch    0.418ms
 1:  router.3550.ch    0.410ms
 2:  bd4.lar01.lna001.bb.fcom.ch   4.561ms
 3:  no reply
 4:  no reply
 5:  2001:4d98:a000::1b4   3.218ms asymm  4
 6:  zhh-015-lo0-0.ip6.ip-plus.net    11.088ms asymm  5
 7:  2001:918:ce::45   6.146ms asymm  6
 8:  2a02:a90:4024:fff:8000::15    5.452ms
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
 Too many hops: pmtu 1500
 Resume: pmtu 1500


Is that a management decision or a technical issue?


Cheers

Jean-Pierre


-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - https://www.hilotec.com/



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Looking for a VoLTE-SIP gateway

[Jean-Pierre Schwickerath]

I've been using the Berofix boxes for about 10 years with various
modules, mostly BRI and FXS. I've one running with a GSM module for for
voice calls. Works like a charm. I've never used the SMS API though.
Hardware quality is perfect and as they are based in Berlin, Support is
in the same timezone and in German if ever need something.


On 14.08.20 12:19, Stanislav Sinyagin wrote:
> cool, thanks, this looks nice. I'll ask them for a quote. Do you have
> them in operation?
>
>
>
> On Fri, Aug 14, 2020 at 10:28 AM Jean-Pierre Schwickerath
> mailto:swi...@hilotec.net>> wrote:
>
> Hi Stan
>
> You should take a look at the Beronet VoLTE SBC:
> https://www.beronet.com/gateway/volte-sbc/
>
> It does all you want, up to 6 SIM slots, SIP routing, SMS via
> REST-API and there is an "app marketplace" where you can install
> OpenVPN as client or server on the box.
>
> Feel free to contact me if you need someone to import one :-)
>
>
> Best Regards
>
> Jean-Pierre
>
>
> On 12.08.20 09:43, Stanislav Sinyagin wrote:
>> hi all,
>>
>> Swisscom will discontinue the old GSM service soon, so I'll need
>> to replace an old gateway.
>>
>> Any recommendation will be appreciated. I'm looking for a
>> ready-made voice gateway, as follows:
>>
>> * 4 or 5 SIM card slots
>> * support for VoLTE and UMTS (in Swiss frequency bands)
>> * Voice calls routed via SIP
>> * API for receiving SMS
>> * Nice to have: support for OpenVPN or some other VPN.
>>
>>
>> thanks,
>> stan
>>
>>
>>
>>
>> -- 
>> Stanislav Sinyagin
>> Senior Consultant, CCIE #5478
>> ssinya...@k-open.com <mailto:ssinya...@k-open.com>
>> +41 79 407 0224
>>
>> ___
>> swinog mailing list
>> swinog@lists.swinog.ch <mailto:swinog@lists.swinog.ch>
>> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>
>
> -- 
> HILOTEC Engineering + Consulting AG - Langnau im Emmental
> IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
> VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
> Tel: +41 34 408 01 00 - https://www.hilotec.com/
>
>
> ___
> swinog mailing list
> swinog@lists.swinog.ch <mailto:swinog@lists.swinog.ch>
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>
>
>
> -- 
> Stanislav Sinyagin
> Senior Consultant, CCIE #5478
> ssinya...@k-open.com <mailto:ssinya...@k-open.com>
> +41 79 407 0224
>
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - https://www.hilotec.com/


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Looking for a VoLTE-SIP gateway

[Jean-Pierre Schwickerath]

Hi Stan

You should take a look at the Beronet VoLTE SBC:
https://www.beronet.com/gateway/volte-sbc/

It does all you want, up to 6 SIM slots, SIP routing, SMS via REST-API
and there is an "app marketplace" where you can install OpenVPN as
client or server on the box.

Feel free to contact me if you need someone to import one :-)


Best Regards

Jean-Pierre


On 12.08.20 09:43, Stanislav Sinyagin wrote:
> hi all,
>
> Swisscom will discontinue the old GSM service soon, so I'll need to
> replace an old gateway.
>
> Any recommendation will be appreciated. I'm looking for a ready-made
> voice gateway, as follows:
>
> * 4 or 5 SIM card slots
> * support for VoLTE and UMTS (in Swiss frequency bands)
> * Voice calls routed via SIP
> * API for receiving SMS
> * Nice to have: support for OpenVPN or some other VPN.
>
>
> thanks,
> stan
>
>
>
>
> -- 
> Stanislav Sinyagin
> Senior Consultant, CCIE #5478
> ssinya...@k-open.com 
> +41 79 407 0224
>
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - https://www.hilotec.com/


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Public Wifi and BüPF

[Jean-Pierre Schwickerath]

Dear colleagues

I'd like to ask if anyone can confirm that the information published on 
https://www.digitale-gesellschaft.ch/publicwlan/ is accurate in regards
to being subject to "Überwachungspflichten gemäss BÜPF".

We have been asked by a customer to sell him a Wifi-Installation for
his café. We are going to sell him the hardware and do the one time
installation. Afterwards the customer is running the infrastructure
himself, he might ask us for help for firmware upgrades and similar
tasks but we are not going to run that Wifi as a service or do any
monitoring. 

If I understand the information on the above page correctly, he doesn't
need to identify his users, so he won't (and won't store any logs) and
as a consequence he will not have any information to be stored for 6
months for the büpf. 
Is that so?

The other question that comes to my mind: if the customer provides a
captive portal to have users acknowledge a "Hausordnung" / code of
conduct, then the APs will "store" which MAC address has checked the
box. Does that make his subject to the Büpf?

Thank you very much for your input on this topic. 


Best Regards

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - https://www.hilotec.com/


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom Webserver via IPv6 down?

[Jean-Pierre Schwickerath]

Hi Jeroen 

  When I reboot the router, I have no SIXXs tunnel for many minutes
  after the underlying pppoe session comes up.
  I was testing IPv6 connectivity with a ping6 to google.
 
 Did you check a traceroute? Or more importantly that you could reach
 the other side of the tunnel? Google is a few hops away at minimum.

The ping was just simple test I was using to confirm connectivity. I
didn't do a traceroute because after trying a few destinations, I was
pretty sure the issue was with the tunnel. 
 
  When I had no
  success I tried pointing a browser to a v6 destination - google
  obviously didn't work, then took swisscom's front page which didn't
  work either.
 
 Which just heavily indicates that your connectivity is broken, one way
 or another (might just be a firewall).
 
  I realized that maybe the tunnel was to blame. So I took it down and
  started it again.
 
 What do you mean with starting it again?

ip tunnel del sixxs
ip link set sixxs down
sleep 1
ip tunnel add sixxs mode sit local 213.180.162.41 remote 213.144.148.74
ip link set sixxs up
ip link set mtu 1280 dev sixxs
ip tunnel change sixxs ttl 64
ip -6 addr add 2001:1620:f00:3c::2/64 dev sixxs
ip -6 route add default via 2001:1620:f00:3c::1 dev sixxs
ip -6 route add 2000::/3 via 2001:1620:f00:3c::1 dev sixxs
ip -6 route add 2001:1620:f1e::/48 dev lo
ip -6 addr add 2001:1620:f1e:1:213:180:162:41/64 dev ppp0

 Seems you have a strange setup, more technical details would be very
 useful.

I'm pretty confident my issue was timing issue. The pppoe session took
long to come up and the sixxs interface was trying to start before
ppp0 was up and thus couldn't bind to the local endpoint. 

Thank you for your help but afaic the issue is sorted out for me. I
check for the local endpoint's ipv6 address at the end of the boot
sequence. If it's not there I restart the sixxs interface and then it
works. 

Cheers

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - http://www.hilotec.com/


signature.asc
Description: PGP signature

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom Webserver via IPv6 down?

[Jean-Pierre Schwickerath]

Hi Martin 
 
 In fact, the 6rd solution was only implemented for residential
 customers, but was never thought to be used for SME products. It only
 worked by chance, as the Border Relays were reachable also from SME
 IP-ranges. We recently had to scale up the border relays, due to
 increased traffic (6rd works extremely well and is highly performant,
 it is about to be enabled for all residential customers by default).

Nice to hear the IPv6 adoption is about to make another big step
forward. 

 At the same time the Border Relays were placed at a different
 location in our network. This means that they are no longer reachable
 from the IP ranges of the SME customers. Hence the interruption, I'm
 sorry it cannot be made to work easily.

That explains why the SME support didn't have a clue what I was talking
about. 

But if it's indeed working as good as you say, why not keep it active
for the SME IP range in the meantime? 

 Again, IPv6 was never officially supported for SME products. An
 official PPPoE-based solution is being worked on, so I hope you
 activate a few tunnels in the meantime and we won't lose you as a
 customer.

Don't worry about me, I'll figure something out. There are still good
tunnel brokers out there. 
Just make sure the CPE / router / firewall vendors and the SC partners
get the technical and organizational details in time to be prepared for
it. 

Thanks for the clarification anyway. 

Regards

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - http://www.hilotec.com/


signature.asc
Description: PGP signature

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom Webserver via IPv6 down?

[Jean-Pierre Schwickerath]

 We assumed a nasty 512k CAM issue in the first place but it seems that
 the Swisscom Webserver is not accessible via IPv6. Anyone else?

I ran into the same issue. I had just rebooted our router and was
testing it when our SIXXS tunnel didn't seem to come up fast enough. I
was cursing it under my breath but soon found out that the problems
were isolated to swisscom. 

I believe some departments at swisscom still consider IPv6 to be an
experiment. After using their 6rd Border Relay for years on those VDSL
CPEs, they seem to have silently switched it off recently - at least
for business customers. SC Support tells me IPv6 is only for private
customers. Go figure. 


Regards


Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - http://www.hilotec.com/


signature.asc
Description: PGP signature

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom Webserver via IPv6 down?

[Jean-Pierre Schwickerath]

Hi Jeroen 

  I ran into the same issue. I had just rebooted our router and was
  testing it when our SIXXS tunnel didn't seem to come up fast enough.
 
 More details about this did not come up fast enough?

When I reboot the router, I have no SIXXs tunnel for many minutes
after the underlying pppoe session comes up.
I was testing IPv6 connectivity with a ping6 to google. When I had no
success I tried pointing a browser to a v6 destination - google
obviously didn't work, then took swisscom's front page which didn't work
either. 
I realized that maybe the tunnel was to blame. So I took it down and
started it again. Then finally when ping6 to google worked, I tried to
refresh my browser's page still pointing at swisscom . That's when I
started to curse but soon decided to go our own webservers and to sixxs
where I was welcomed with IPv6. 

I will have to look into the interfaces' configuration - maybe this
weekend. Perhaps the problem is that the sixxs tunnel interface is
trying to start too soon although it's linked to the ppp-interface and
is supposed to wait for it coming up before it activated itself. I shall
try again after introducing a delay before the tunnel tries to start. 
I'll let you know if I still have troubles. 

 They likely switched it off as enabling it means that those business
 customers suddenly have IPv6 which they are not firewalling, hence,
 not what they want.
 
 The other reason might be that 6rd does not perform that well which
 thus causes support calls for important paying customers...

It was never activated by default on the business CPEs and everyone
doing to needed to do it on purpose by entering the 6rd details. So
hopefully those people had a firewall concept - but you never know. 
What makes me the most angry is that they switched it off without
prenotice and there is no information about it anywhere, neither on the
labs-page nor in the partner portal. 

Either I have to switch to a SC wholeseller who offers native v6
or I shall be activating a few tunnels for those customers who are now
deprived of 6rd. And I though Martin told us at a swinog event that 6rd
was a permanent decision for SC's pppoe customers. 

Best Regards

Jean-Pierre


-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - http://www.hilotec.com/


signature.asc
Description: PGP signature

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Belgian spammer

[Jean-Pierre Schwickerath]

 If you are going to complain about someone, could you at least include
 headers of these spams?
 
 Also, it would be prudent to contact the ISP that the spamvertised
 sites are located.

I'd suggest to post your full spam message in the form on
www.spamcop.net and it will give you all the abuse contacts of the
networks involved in the message (headers, body and URIs). 

Regards

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 408 01 00 - http://www.hilotec.com/


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] How to automate abuse complaints for ip based violations

[Jean-Pierre Schwickerath]

Hi Markus 

So, what alternatives are there? 

How about using services from Dshield
(http://www.dshield.org/howto.html) or Threatstop
(http://www.threatstop.com/IP-Reputation-Service-Overview especially
step 5)

Basically you submit your logs and they do the lookup for you and you
can benefit from getting offendig IPs from other ISPs. 


Regards

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 408 01 00 - http://www.hilotec.com/


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SIP gateway service documentation

[Jean-Pierre Schwickerath]

Hello Stan

 The SP puts forward a number of requirements, such as
 national/international context in To: field, then some special
 requirements for CallerID privacy, etc. The problem is, we can't get
 a document that describes the technical details of the interface, and
 SP refuses to create such a document. All we've got is a number of
 emails and some information from phone conversations.

SIP and its extensions are fairly well standardized. Have a look at 
http://www.packetizer.com/ipmc/sip/standards.html for an overview of
those RFCs. 
We all know the PBX manufacturers and their developers seldom fully
comply to the standards so they should give you a good starting point
on how it's supposed to be done. You will have to test each and every
case with your SP unless he can garantee you he has implemented it
fully standard compliant. 

 Is it a common situation for such a service? Am I too naive with my
 expectations to receive a fully documented service? If it were a
 no-name lousy cheap service provider, I wouldn't ask :) 

We never had any issues when connecting SIP trunks to a provider as
long as they were using RFC compliant SIP (IMHO the RFC compliance is a
major decision point when choosing the SP). And I second you on the
point that the SP should document its extensions to the protocol if
they are not standard compliant extensions.

Regards

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 402 74 00 - http://www.hilotec.com/


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Anyone else having strange attachment lost effects when delivering mails to @bluewin.ch accounts?

[Jean-Pierre Schwickerath]

Hi 
 
 Is anyone else seeing such things?

Yes, we see the same type of effect. 

Our customers are on cybernet-xDSL connections and send their mails
through smtp.cybernet.ch. I guess they must have a similar config as
the bluewin smtp servers. 

The mails simply get lost and never reache the destination
mailserver. Sometimes a mail sent to multiple recipients (all on our
mailservers) only reaches a few of them. I have no clue what kind of
black magic is done on the cybernet smtp servers, but it's very
frustrating. I didn't particularly monitor whether mails with and
without attachements are affected in different ways. 

Another thing I saw is that mails sent to an non-swisscom mailserver on
port 25 (non encrypted but authenticated) got a X-Achtung Spam: 
inserted after the headers, causing it to be rejected by some final
destination mailservers because the header is invalid (it's preceed by
a blank line). That must be because of the smtp-session-highjacking the
incumbant is doing. 

Anyway, we have been very busy lately to move more and more customers
to not only use our mailservers but certainly encrypt their connections
as to avoid someone fussing with the payload. 
I've definitely lost any trust in the smtp service offered by the
access providers. 


Regards

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 402 74 00 - http://www.hilotec.com/


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Juge d'instruction du canton de Vaud

[Jean-Pierre Schwickerath]

Hi Andreas


 Our draft answer:
 http://www.fink.org/vaud-answer02dez2009.pdf

I can't comment the legal part but you should have the letter proofread
before sending it. There are a lot of das that should be , dass,
there are words which are wrongly capitalized and there are lot of
missing commas...

Cheers

Jean-Pierre


-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 402 74 00 - http://www.hilotec.com/

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] RE: Switzerlandwide Internet problem

[Jean-Pierre Schwickerath]

Hi everyone, 

 No known problems/attacks, also all statistics look fine here.


http://tools.cybernet.ch/status/detail.php?tt_id=2127

We experienced outages on ip-plus and cybernet adsl connections. The
adsl connection itself was up but no traffic came through. 
The whole late afternoon and evening connectivity was a game of luck. 



Regards

Jean-Pierre



-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Germany: using blacklists now illegal?

[Jean-Pierre Schwickerath]

Greetings, 

 In case Az. 7 O 80/07, the District Court of Lüneburg has ruled
 that the use of blacklists for mail filtering is an illegal process.
 The court thereby confirmed the view of a known spammer that the fact
 that mails from his servers were deleted by the SPAM filter was an
 act of censorship.
 
 According to the ruling, the fact that a mail server is used to
 transmit soleily SPAM is not sufficient to block mails from it
 entirely. Blocking a single mail address would have been sufficient,
 according to the court. However, even this step would only have been
 acceptable in order to prevent an immanent danger of a virus attack.

According to a c't article, they seem to interprete it in the way that
if you reject the mail during the smtp transaction, this ruling doesn't
apply because you didn't delete the mail (you never accepted it = it
was never successfully sent from the sending mailserver). 

The article also stated that it was the case of an ISP blocking the IP. 

So if you allow your customers to define which blacklist they want to
use and which not or if you put all the spam into a separate folder
(and thus not delete it after the smtp transaction was successfully
completed), you should be fine. 


Regards


Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] vtx ADSL /30 subnet practice

[Jean-Pierre Schwickerath]

 Can anybody confirm that this is current practice at vtx?  Are other
 providers doing the same?

On a cybernet 4-IP-Addresses ADSL setup I can actively use the two
middle IPs in a BRouter setup, the router using the lower address. 

The vtx setup you describe is indeed kind of useless. If it's truth
then I guess the vtx people need an update on best practice
recomendations.



Regards,

Jean-Pierre
-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] to SPF or not to SPF

[Jean-Pierre Schwickerath]

 If the provider on which one is guesting has a policy to block
 outbound access from their network to all ports used for sending of
 mail, so that they can force one through their SMTP server for sake
 of control, micromanagement, or whatever, then (assuming they know
 about it), would they not then block official port 587 as well as
 port 25?  That was the position I heard the 'customer service rep'
 take the last time I tried to solve such a problem through appeal to
 bureaucratic sensibility.  


What I'm going to say is not new, but I guess we have a lot of trouble
with SMTP because the same port is used as well for the communication
between 2 MTAs as for between a MUA and a MTA. 
I don't know about any provider that doesn't require smtp auth on port
587. 
ISPs should block outgoing connections to port 25 unless they know the
source is a SMTP MTA. I guess this would mitigate a lot of zombies as
it would force them to use the provider's smtp server (which does
outbound spam/virus filtering and ISPs can easily identify their own
customers). Alternatively the zombie would use a remote port 587 but it
would require authentication so again the identification of the owned
machine / user would be possible. 


Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] to SPF or not to SPF

[Jean-Pierre Schwickerath]

 All mailing list forward mail with the original sender in the
 enveloppe 

Not true: Mails from the swinog-mailinglist reach my mailserver with
[EMAIL PROTECTED] as sender envelope address

 and if you forward your mail on one server to another one
 with e.g. a simple .forward rule it will also re-use the same
 envelope from address. Forwarding mail is very common and it is
 important to use the same envelope form address in the forwarding
 path. Everybody who denies this fact does not understand the email
 system and the way bounces work.

If you chose to forward mail this way, then you'd better make sure that
the destination mail server doesn't apply spf checks for mails coming
from the relaying server. or that the forwarding server rewrites the
sender address. 

If you're a provider that allows its users to forward their mail to
remote addresses, then I'd advise you to use sender rewriting and thus
offer your customers a reliable mail relaying. That's a marketing
argument. 


But in the end, everyone can do whatever they want to do ;-)

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] to SPF or not to SPF

[Jean-Pierre Schwickerath]

Hi, 

 1. Serious design flaws (such as the forwarding problem).

SPF is there to prevent mail with your sender envelope address to be
relayed/forwarded by mailservers that are not meant to use your
address. When you forward a mail in your MUA, you don't use the
original sender in the From: header, do you?
When a mailserver is relaying mail it is supposed to use its own sender
envelope address. One possibility for that is SRS. 
 
 2. Peopele who don't understand SPF. If the not-understandig is a 
 mailserver admin it gets fatal (and lots of them are).
 
 Both leads to legitimate rejected mail (And not just some false 
 positives, sometimes complete domains get locked out by 
 mailservers).
 
 So consider

That is a problem which in not restricted to SPF. If a mailadmin
doesn't know how to use an RBL and blocks everything, then he can't be
helped. 

 * Think twice before publishing SPF Records for your Domains. 
 There are admins in the wild who treat neutral as hard fail.

I haven't had the chance to be in this situation yet. 

 * I use SPF to reject mails with spoofed origings from my private 
 mailserver. The number of rejected mails because of failed SPF 
 checks is less than one percent of all REJECTED email. If I 
 wouldn't be doing it for studies about mail, SPAM and means 
 against it I'd completely let it be. It's not worth the effort 
 to support a standard which is broken by design and so rarely 
 used.

If you consider SPF to be the solution against all kinds of SPAMs then
you will indeed be disapointed. SPF is meant to prevent the abuse of
your domain as mail envelope from address. 
There are still worms out there that use harvested e-mail addresses as
sender. And when the people receiving this kind of spam come back to
you, you can at least tell them: hey, we published spf records to show
you which IPs are allowed to send mail with this envelope address. if
you don't check it and accept the obvious forgery, then it's your
problem. 


Regards,

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

[Jean-Pierre Schwickerath]

Hi Tonnerre, 

 From a cryptographical point of view, this would be a dangerous setup.
 You're transmitting the same message encrypted (local MX - Client)
 as well as unencrypted (sending MX - local MX). This leaves you
 open to a known plaintext attack against your server's private key,
 because it gives you an opportunity to gain more and more information
 about the key in use, and all you have to do is send regular-looking
 SPAM to the user.

What kind of explanation is this? 
If the local MX is relaying the message it will add Received headers
which will modify the message, thus starting a known plaintext attack
on that communication is an adventurous thing.
And you still have to interceipt both communications. And even then,
given timestamps and nonces I guess you're heading nowhere...

But basically what you say is that every website that is available
though HTTP and HTTPS is subject to an attack against its private key. 


We offer STARTTLS over SMTP and SMTP over SSL for our custommers that
want to relay their mail over our mailservers (with authentication). 
We also offer POP3 over SSL and Webmail over HTTPS in order to protect
the passwords of our custommers. 
We recommend everyone to use it but we can't force it. 


Regards. 
Jean-Pierre


-- 
HILOTEC Engineering + Consulting AG
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] URI extractor script

[Jean-Pierre Schwickerath]

Hello, 

on the NANOG-List people are currently slaughting each other in matters
of RBL-Usage and -Policy. 
This reminded me of a project I've been wanting to start for a long
time. 

Does someone have a decent script that would extract URIs from mails
that have been classified as spam in order to feed an URIDNSBL with it?


Regards. 
Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] [EMAIL PROTECTED] - anyone from bluewin in here?

[Jean-Pierre Schwickerath]

 There is a massive mail loop (exhange server processing wrong
 CC-recipient list) running all over switzerland at the moment.
 Bluewin servers (mail11 / mail13 / ...) seem to have tousands of
 mails in the queue.
 
 Can anyone please delete them and block the sender's address 
 [EMAIL PROTECTED]
 
 It's not an issure we can solve here with the spam filter, the mail
 flood is going to approx. 150 recipients, but only 3 of them are
 hosted here, the others receive the mails over and over.
 
 We already informed the operator of defective exchange server, that
 machine is down for the moment, but the bluewin queues are full with
 that garbadge.

Glad to see we're not the only one with this problem 



Jean-Pierre
-- 
HILOTEC Engineering + Consulting GmbH
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] future of dls

[Jean-Pierre Schwickerath]

  I know is that all the 'excessive' bandwidth available with VDSL
  will only be used for HDTV streaming. So don't hold your breath for
  20Mbit Internet surfing.
 
 Ack!
 
 TV streams will have strict priority over internet traffic. So surfing
 at 
 (very) highspeed and hdtv streaming won't be possible.

Thanks for all that useful information. 

We'll look forward into packing normal data into video streams ;-)


Jean-Pierre

-- 
HILOTEC Engineering + Consulting GmbH
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] hotmail requires sender id

[Jean-Pierre Schwickerath]

 There is a 'small' problem with this. AOL uses SPFv1, while Microsoft
 is pushing SPFv2, which is not really SPFv2, but their own version
 of the thing which clashes with the real SPFv1 (openspf.org one) also
 called classic and that is the one people have been deploying the last
 2 years, not the one with the PRA checks.
 
 The problem here is that Mickeysofts version of SPF breaks all SPFv1
 installations
 
 The IESG has apparently given both drafts (SPFv1 + Sender-ID/SPFv2)
 the chance to go to experimental RFC.

OK, maybe I talked to fast, or wrote without thinking too much. 
I completely oversaw the license issue and the fact that their sender ID
stuff is breaking the currently used SPFv1. 

I'll have to look deeper into the issue. Meanwhile I signed the openspf
position. 


Regards, 

Jean-Pierre

-- 
HILOTEC Engineering + Consulting GmbH
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] hotmail requires sender id

[Jean-Pierre Schwickerath]

 Ignore it and if a hotmail customer complains to you, tell them their
 hotmail SPAM filter is busted and you can not do anything against it.
 The hotmail users should start yelling at Microsoft and not at anybody
 else.

I wouldn't see it so bad. First, they'll start in november which leaves
some time to the rest of the world to adapt to the situation. Second, I
think it's a good point to promote SPF ( I know we already hat the
discussion about whether SPF is good or bad ). Third, it seems as if the
message will only be tagged as spam and not deleted or rejected. It's
like giving spamassassin a high score for SPF. 

With AOL and now Microsoft (counting only the really big ones) adopting
SPF I see a real chance for this technology to be successfully used. 

Best regards,

Jean-Pierre

-- 
HILOTEC Engineering + Consulting GmbH
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] ohh, what a surprise: Breitband viel zu teuer

[Jean-Pierre Schwickerath]

Hello, 
 
 And innovations.. Please :) In one of the last Netzwoche sunrise was
 asked to say which kind of innovations the would launch if they would
 have the last mile and the answer was something like ahem.. what was
 the question again?
 
 Just my 5 cents for this evening but I would appreciate some other
 opinions about this issue that is getting more and more HOT.. 

I lived in Germany for the last years and the big different from the
consumer side is that in Germany you have tons of different offers you
can order. And most of them have different prices, so in fact if you
decide to get a broadbast connection you start to compare prices. In
Switzerland, I believe every ADSL connection type 600/100, 1200/200,
2400/200 cost the same at most providers: 49.-, 69.-, 89.-
There is no competition. It makes virtually no difference whether to go
to swisscom, sunrise, cybernet, ...
Sure it's easier to choose for the point of view of the consumer, but
the prices will certainly not reflect the real expenses of the ISPs for
these types of connections.


Regards, 
Jean-Pierre
-- 
HILOTEC Engineering + Consulting GmbH
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SPF implementation

[Jean-Pierre Schwickerath]

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/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog