[swinog] high delay with icmp

2008-10-20 Diskussionsfäden Adrian Kägi
The accessibility to www.google.com and a lot of other web sites, was
yesterday the whole very slow!

Icmp from Sunday 2008-10-19 18.00
Antwort von 209.85.135.103: Bytes=32 Zeit=121ms TTL=242
Antwort von 209.85.135.103: Bytes=32 Zeit=117ms TTL=242
Antwort von 209.85.135.103: Bytes=32 Zeit=118ms TTL=242
Antwort von 209.85.135.103: Bytes=32 Zeit=119ms TTL=242

Traceroute:
   11 ms1 ms1 ms  . [192.168.10.1]
   2 7 ms 6 ms 7 ms  10.14.0.1
   3 7 ms 9 ms 8 ms  tr-1430019570.zapp.ch [213.213.160.65]
   4 7 ms 7 ms14 ms  108-160-213-213.static.zapp.ch
[213.213.160.108]
   5 9 ms10 ms 8 ms  62-2-42-33.static.cablecom.ch [62.2.42.33]
   612 ms11 ms11 ms  ch-zrh01a-ra1-ge-1-1-0.aorta.net
[213.46.171.49]
   712 ms12 ms12 ms  tix.net.google.com [194.42.48.58]
   8   110 ms   110 ms   120 ms  64.233.174.34
   9   118 ms   120 ms   126 ms  72.14.238.128
  10   116 ms   122 ms   118 ms  209.85.241.189
  11   127 ms   130 ms   124 ms  209.85.253.26
  12   120 ms   119 ms   120 ms  www.google.com [209.85.135.147]

Icmp from today 2008-10-20 08:30
Antwort von 209.85.135.99: Bytes=32 Zeit=23ms TTL=243
Antwort von 209.85.135.99: Bytes=32 Zeit=22ms TTL=243
Antwort von 209.85.135.99: Bytes=32 Zeit=21ms TTL=243
Antwort von 209.85.135.99: Bytes=32 Zeit=20ms TTL=243

Any known problems??

Best regards!
Adrian


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


[swinog] WG: URIBL.COM ACL Change for 195.141.232.251

2008-10-20 Diskussionsfäden Xaver Aerni
Hello,

  We receive yesterday this mail.
 It is verry interessing. This is our DNS Server and some 
 Webservices and Monitoring Tools. We havn't any Mail Services 
 on this Server.
 Did somebody know about this new Rules

Greetings Xaver

 -Ursprüngliche Nachricht-
 Von: URIBL DNS Admin [mailto:[EMAIL PROTECTED] 
 Gesendet: Sonntag, 19. Oktober 2008 22:48
 An: [EMAIL PROTECTED]
 Betreff: URIBL.COM ACL Change for 195.141.232.251
 
 Greetings,
 
 We are contacting you because you are identified as the 
 technical or abuse contact for the IP address or domain listed below.
 
 We have made a policy change on the public mirrors that 
 handle queries for multi.uribl.com.  The following changes 
 apply to the IP addresses listed below. 
 
 IP Address: 195.141.232.251
 PTR Record: ns2.pop.ch
 Current Policy: Allow
 New Policy: BLOCK - Positive Responses
 Effective : In 30 days
 
 If the new policy is to block queries from 195.141.232.251, 
 and you are unaware that you are sending high volume queries 
 to our public mirrors, or if you do not need the URIBL 
 service, please make sure it is shut off on your high traffic 
 filtering devices as not to flood the public dns system.
 
 If you recently upgraded to SpamAssassin 3.x, URIBL was 
 included by default.  It can easily be disabled by adding the 
 following lines to your spamassassin/local.cf:
 
score URIBL_BLACK 0
score URIBL_RED 0
score URIBL_GREY 0
 
 If you are a high volume user and rely on URIBL to filter 
 email, our commercial data feed service does allow you to 
 obtain a copy of the
 data to query locally.   Please see 
 http://www.uribl.com/datafeed.shtml
 for more information on requesting the data feed service.
 
 If 195.141.232.251 is a primary resolver for many of your 
 customers, there is a chance that a single client is 
 accounting for a majority of the query volume we are seeing.  
 If you can remove the heavy users on your end, and the volume 
 drops to a manageable level, we will be willing to answer 
 queries from 195.141.232.251.
 
 If you cannot make changes to the systems that are sending 
 these queries, please forward this message to the appropriate 
 person who can.  URIBL may return positive replies for all 
 queries if no action is taken after a reasonable amount of time.
 
 If you have any questions about this notification, you may 
 reply to this email.
 
 Thank you for your time,
 
 --
 URIBL DNS Admin
 [EMAIL PROTECTED]
 http://uribl.com
 
 
 
 

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


Re: [swinog] WG: URIBL.COM ACL Change for 195.141.232.251

2008-10-20 Diskussionsfäden Xaver Aerni
Yes and Some companies are using our DNS for repication.
Since then we have many DNS Requests.
- Original Message - 
From: Silvan Gebhardt [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 20, 2008 9:51 AM
Subject: Re: [swinog] WG: URIBL.COM ACL Change for 195.141.232.251


Do you have clients using this DNS Server? I would see through the logs
- someone with a mailserver is using this DNS Box for all DNS queries

- Has nothing to do with having mail services on it!
S.

Xaver Aerni schrieb:
 Hello,

   We receive yesterday this mail.
  It is verry interessing. This is our DNS Server and some
  Webservices and Monitoring Tools. We havn't any Mail Services
  on this Server.
  Did somebody know about this new Rules

 Greetings Xaver

 -Ursprüngliche Nachricht-
 Von: URIBL DNS Admin [mailto:[EMAIL PROTECTED]
 Gesendet: Sonntag, 19. Oktober 2008 22:48
 An: [EMAIL PROTECTED]
 Betreff: URIBL.COM ACL Change for 195.141.232.251

 Greetings,

 We are contacting you because you are identified as the
 technical or abuse contact for the IP address or domain listed below.

 We have made a policy change on the public mirrors that
 handle queries for multi.uribl.com.  The following changes
 apply to the IP addresses listed below.

 IP Address: 195.141.232.251
 PTR Record: ns2.pop.ch
 Current Policy: Allow
 New Policy: BLOCK - Positive Responses
 Effective : In 30 days

 If the new policy is to block queries from 195.141.232.251,
 and you are unaware that you are sending high volume queries
 to our public mirrors, or if you do not need the URIBL
 service, please make sure it is shut off on your high traffic
 filtering devices as not to flood the public dns system.

 If you recently upgraded to SpamAssassin 3.x, URIBL was
 included by default.  It can easily be disabled by adding the
 following lines to your spamassassin/local.cf:

score URIBL_BLACK 0
score URIBL_RED 0
score URIBL_GREY 0

 If you are a high volume user and rely on URIBL to filter
 email, our commercial data feed service does allow you to
 obtain a copy of the
 data to query locally.   Please see
 http://www.uribl.com/datafeed.shtml
 for more information on requesting the data feed service.

 If 195.141.232.251 is a primary resolver for many of your
 customers, there is a chance that a single client is
 accounting for a majority of the query volume we are seeing.
 If you can remove the heavy users on your end, and the volume
 drops to a manageable level, we will be willing to answer
 queries from 195.141.232.251.

 If you cannot make changes to the systems that are sending
 these queries, please forward this message to the appropriate
 person who can.  URIBL may return positive replies for all
 queries if no action is taken after a reasonable amount of time.

 If you have any questions about this notification, you may
 reply to this email.

 Thank you for your time,

 --
 URIBL DNS Admin
 [EMAIL PROTECTED]
 http://uribl.com





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

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


Re: [swinog] high delay with icmp

2008-10-20 Diskussionsfäden Steven.Glogger
nope, no clue...
i've not seen any issues or got any alarms.
maybe cablecom had (again?) bandwidth issues?

-steven

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Kägi
Sent: Monday, October 20, 2008 8:38 AM
To: [EMAIL PROTECTED]
Subject: [swinog] high delay with icmp

The accessibility to www.google.com and a lot of other web sites, was
yesterday the whole very slow!

Icmp from Sunday 2008-10-19 18.00
Antwort von 209.85.135.103: Bytes=32 Zeit=121ms TTL=242
Antwort von 209.85.135.103: Bytes=32 Zeit=117ms TTL=242
Antwort von 209.85.135.103: Bytes=32 Zeit=118ms TTL=242
Antwort von 209.85.135.103: Bytes=32 Zeit=119ms TTL=242

Traceroute:
   11 ms1 ms1 ms  . [192.168.10.1]
   2 7 ms 6 ms 7 ms  10.14.0.1
   3 7 ms 9 ms 8 ms  tr-1430019570.zapp.ch [213.213.160.65]
   4 7 ms 7 ms14 ms  108-160-213-213.static.zapp.ch
[213.213.160.108]
   5 9 ms10 ms 8 ms  62-2-42-33.static.cablecom.ch [62.2.42.33]
   612 ms11 ms11 ms  ch-zrh01a-ra1-ge-1-1-0.aorta.net
[213.46.171.49]
   712 ms12 ms12 ms  tix.net.google.com [194.42.48.58]
   8   110 ms   110 ms   120 ms  64.233.174.34
   9   118 ms   120 ms   126 ms  72.14.238.128
  10   116 ms   122 ms   118 ms  209.85.241.189
  11   127 ms   130 ms   124 ms  209.85.253.26
  12   120 ms   119 ms   120 ms  www.google.com [209.85.135.147]

Icmp from today 2008-10-20 08:30
Antwort von 209.85.135.99: Bytes=32 Zeit=23ms TTL=243
Antwort von 209.85.135.99: Bytes=32 Zeit=22ms TTL=243
Antwort von 209.85.135.99: Bytes=32 Zeit=21ms TTL=243
Antwort von 209.85.135.99: Bytes=32 Zeit=20ms TTL=243

Any known problems??

Best regards!
Adrian


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


[swinog] Open position @IP+

2008-10-20 Diskussionsfäden Andre Chapuis
Hi,

http://www.swisscom.com/SCMCMS/Scripts/PopupJobEngine.aspx?frameurl=https://jobsp.swisscom.com/sap/bc/webdynpro/sap/hrrcf_a_unreg_jo
b_search?sap-wd-configId=ZAPPLWI_UNREG

Search for: CBU-50315754

André
--
André Chapuis
Swisscom IP-Plus
Genfergasse 14
3050 Berne
+41 31 342 40 74
[EMAIL PROTECTED]
CCIE #6023
--

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


Re: [swinog] high delay with icmp

2008-10-20 Diskussionsfäden Adrian Kägi
Hmmm, i think it was/is (!) a fault from cc...
I started a trouble ticket.
Thx for answer!

Adrian

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Im Auftrag von [EMAIL PROTECTED]
Gesendet: Montag, 20. Oktober 2008 09:21
An: [EMAIL PROTECTED]
Betreff: Re: [swinog] high delay with icmp

nope, no clue...
i've not seen any issues or got any alarms.
maybe cablecom had (again?) bandwidth issues?

-steven

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Adrian Kägi
Sent: Monday, October 20, 2008 8:38 AM
To: [EMAIL PROTECTED]
Subject: [swinog] high delay with icmp

The accessibility to www.google.com and a lot of other web sites, was
yesterday the whole very slow!

Icmp from Sunday 2008-10-19 18.00
Antwort von 209.85.135.103: Bytes=32 Zeit=121ms TTL=242
Antwort von 209.85.135.103: Bytes=32 Zeit=117ms TTL=242
Antwort von 209.85.135.103: Bytes=32 Zeit=118ms TTL=242
Antwort von 209.85.135.103: Bytes=32 Zeit=119ms TTL=242

Traceroute:
   11 ms1 ms1 ms  . [192.168.10.1]
   2 7 ms 6 ms 7 ms  10.14.0.1
   3 7 ms 9 ms 8 ms  tr-1430019570.zapp.ch [213.213.160.65]
   4 7 ms 7 ms14 ms  108-160-213-213.static.zapp.ch
[213.213.160.108]
   5 9 ms10 ms 8 ms  62-2-42-33.static.cablecom.ch [62.2.42.33]
   612 ms11 ms11 ms  ch-zrh01a-ra1-ge-1-1-0.aorta.net
[213.46.171.49]
   712 ms12 ms12 ms  tix.net.google.com [194.42.48.58]
   8   110 ms   110 ms   120 ms  64.233.174.34
   9   118 ms   120 ms   126 ms  72.14.238.128
  10   116 ms   122 ms   118 ms  209.85.241.189
  11   127 ms   130 ms   124 ms  209.85.253.26
  12   120 ms   119 ms   120 ms  www.google.com [209.85.135.147]

Icmp from today 2008-10-20 08:30
Antwort von 209.85.135.99: Bytes=32 Zeit=23ms TTL=243
Antwort von 209.85.135.99: Bytes=32 Zeit=22ms TTL=243
Antwort von 209.85.135.99: Bytes=32 Zeit=21ms TTL=243
Antwort von 209.85.135.99: Bytes=32 Zeit=20ms TTL=243

Any known problems??

Best regards!
Adrian


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

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


Re: [swinog] RBL's (again) (Was: Anyone from Green here?)

2008-10-20 Diskussionsfäden Marco Fretz
Hi Tonnerre,

You got me wrong :-)

What I'm trying to say is: As a mail service provider (recipient side)
you can use greylisting and if there are some buggy mailers out there in
the internet (or in your local network) it's not a greylisting problem
and it's not your problem. they have to fix there mailer problems
(sender side). it's not the ISP who has to adapt mail services to
buggy customer stuff ^^

A mailer script which doesn't support queueing or in other words
RFC-conform MTA operation will cause problems anyway regardless if
greylisting is used or not, other 4xx codes, etc...

maybe my opinion is very radical but I think it's the way it should be.
Of course I know there are exceptions with individual customer
situations, etc.

bests
 Marco

Tonnerre Lombard wrote:
 Salut, Marco,
 
 On Fri, 17 Oct 2008 15:21:59 +0200, Marco Fretz wrote:
 Of course I know what you mean. That's the thing every webhoster have
 to fight with. Last year I was on the Secure Linux Admin Conference in
 Berlin. There was a workshop how to protect shared hosting
 webservers...
 
 I am talking about the recipient side. I don't think it's a safe
 assumption that all scripts _your_ _mail_ _users_ will receive mail
 from are under your control.
 
 If I remember correctly the 2nd or 3th step was: prevent the users
 from using SMTP (or any other port) to the internet and only allow the
 destination you choose, your mailrelay servers, http proxy, etc.
 
 That is great, but not everyone does that. In fact the number of
 providers which do that is fairly low. I would do so myself, also for
 the reason that this prevents people owning a web service to spam
 around in a volatile manner, but that's not the point at all.
 
 crap customer scripts don't look like a reasonable argument against
 greylisting to me. though some webhosting customers might send mails
 with their mailer script to recipients which are not on your mail
 server and this other mail server maybe is also protected with
 greylisting, ergo same problem ergo problem not solved...
 
 For the receiving server, it is.
 
 do you see what I mean, now? :) or maybe I didn't fully understand the
 issue you had.
 
 No, you don't.
 
 but agreed it's always hard to decide if you want secure systems or
 happy users.
 
 That would be true if there was no way around greylisting, but there is.
 
   Tonnerre
 
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] RBL's (again) (Was: Anyone from Green here?)

2008-10-20 Diskussionsfäden Tonnerre Lombard
Salut, Marco,

On Mon, 20 Oct 2008 14:15:41 +0200, Marco Fretz wrote:
 What I'm trying to say is: As a mail service provider (recipient
 side) you can use greylisting and if there are some buggy mailers
 out there in the internet (or in your local network) it's not a
 greylisting problem and it's not your problem. they have to fix there
 mailer problems (sender side). it's not the ISP who has to adapt
 mail services to buggy customer stuff ^^

Or maybe you just didn't listen...

Tonnerre



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