> Greylisting only delays mails. Proper spammers just use ISP relays and
> then they will try forever. Or they will just nicely do the full SMTP
> thing for the first message and try again later, or stall sending to you
> as the 450 is recognized and spam run you again later. So many easy ways
> around it and it only causes annoyance.
I don't know anything about proper spammers. Greylisting has reduced the
amount of incoming spam significantly, probably at 90-95%. Of course there
are spambots which play around greylisting, but they aren't yet that widely
used.
> On top of that, I guess you have whitelisted large mail providers like
> gmail who try to send a single mail from several IP's, thus hitting your
> greylist over and over again, and then just giving up? :)
some greylisting packages have their whitelists already pre-filled in the
distribution package, so it works quite well (we used
http://policyd.sourceforge.net/ , and I have no complaints about this
software, and neither do the users.
On Mon, Oct 20, 2008 at 10:51:28AM +0200, Adrian Kägi wrote:
> Hmmm, i think it was/is (!) a fault from cc...
> I started a trouble ticket.
(!)
google is probably using some form of anycast.
(I would personnaly travel much more if crossing the atlantic had a cost of 50ms :-)
--
Philippe Strauss
http://philou.ch
nope, no clue...
i've not seen any issues or got any alarms.
maybe cablecom had (again?) bandwidth issues?
-steven
-----Original Message-----
From: swinog-bounces(a)lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Adrian Kägi
Sent: Monday, October 20, 2008 8:38 AM
To: swinog(a)swinog.ch
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:
1 <1 ms <1 ms <1 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 ms 14 ms 108-160-213-213.static.zapp.ch
[213.213.160.108]
5 9 ms 10 ms 8 ms 62-2-42-33.static.cablecom.ch [62.2.42.33]
6 12 ms 11 ms 11 ms ch-zrh01a-ra1-ge-1-1-0.aorta.net
[213.46.171.49]
7 12 ms 12 ms 12 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(a)lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
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:dnsadmin@uribl.com]
> Gesendet: Sonntag, 19. Oktober 2008 22:48
> An: admin(a)pop.ch
> 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
> dnsadmin(a)uribl.com
> http://uribl.com
>
>
>
>
actually greylisting works pretty well, and the whitelist
of exceptions is relatively small (not more than 300 entries as
far as I remember). Also if you communicate the value
of it to the customers, they tend to agree that having 90% of spam
filtered before entering the system is worth waiting for half an hour
for email from a new source.
It's also a matter of resources: if you don't want or cannot enable
greylisting, you have to invest more resources into a more sophisticated
mail filtering software. Even if it's available for free, still developing
and maintaining your solution might become too expensive.
so, basically as we discussed it already last week in regards to Skype:
use the right tools for the right task :-)
----- Original Message ----
> From: Tonnerre Lombard <tonnerre(a)bsdprojects.net>
> To: swinog(a)swinog.ch
> Cc: swinog(a)lists.swinog.ch; per.jessen(a)enidan.ch
> Sent: Friday, October 17, 2008 5:27:10 PM
> Subject: Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
>
> Salut, Per,
>
> On Fri, 17 Oct 2008 12:47:48 +0200, Per Jessen wrote:
> > Another option is to disable greylisting just for that one
> > mailserver.
>
> This implies that either you know all servers hosting broken scripts
> (NP-complete I think) or your customers will always communicate
> problems. Usually they encounter them and rant about it on their
> Stammtisch and then change provider to someone with one hell of a lot
> of SPAM.
>
> Tonnerre
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:
1 <1 ms <1 ms <1 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 ms 14 ms 108-160-213-213.static.zapp.ch
[213.213.160.108]
5 9 ms 10 ms 8 ms 62-2-42-33.static.cablecom.ch [62.2.42.33]
6 12 ms 11 ms 11 ms ch-zrh01a-ra1-ge-1-1-0.aorta.net
[213.46.171.49]
7 12 ms 12 ms 12 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
Dear all
Energie Wasser Bern (ewb) Telecom is hiring a project manager for our
darkfiber backbone.
For further details visit this link:
http://www.jobs.ch/inserate-detail/Information-technology-Telecom/Projec
t-management/Projektleiter-in-Telekommunikation--/Energie-Wasser-Bern/Be
rn/1832261/58/1/0
Please send applications to the contact mentioned in the job ad.
Regards,
Energie Wasser Bern
Ruedi Hofer
Network Engineer
Monbijoustrasse 11, Postfach
3001 Bern
Inspired by a thread on cisco-nsp (
https://puck.nether.net/pipermail/cisco-nsp/2008-October/055260.html) I was
wondering if there was network device testing/packet generating equipment
(be it a Spirent SmartBits or Agilent N2X (thanks for sponsoring
Swinog-13)or anything similar) to borrow/for rent in the swinog
community ?
Until now I've mostly used iperf et al to test equipment - what are your
opinions and experiences regarding testing/troubleshooting/benchmarking
network equipment ?
Best regards (and until next week at Swinog-17),
Aarno
--
Atrila GmbH
Aarno Aukia
0764000464