swinog

swinog@lists.swinog.ch

2 participants
2989 discussions

Re: [swinog] [swinog-core] SwiNOG-26 (Update)
by Michel Renfer 14 Feb '13

14 Feb '13

Sali Zäme Die GVs... ;-p Aus meiner Sicht gibt es folgende Möglichkeiten: - Termin im März / April (Abendessen) - Vorabend SwiNOG-26 - Im Juli bei mir auf der Terasse ;-) gruss michel swinog(a)swinog.ch wrote: > Hoi Michel > >> Ich habe Gutes zu berichten > > Aber Hallo. Wir sind also gut besetzt für das nächste SwiNOG. :) > > Dann wäre es ja eigentlich einmal Zeit für zwei GVs und eine > Vorstanssitzung... :-P > >> Insofern könnte man dem Gurtenpark den Do, 23.Mai definitiv bestätigen > > Keine Angst, der Termin wird schon nicht anderweitig vergeben. > > Grüsse > Roman >

1 0

Call for sponsors SwiNOG #26
by Michel Renfer 11 Feb '13

11 Feb '13

Dear SwiNOG Community We just published the 'Save-the-date' for SwiNOG-26. For the next event we still have some sponsoring possibilities available. If you are interested to be part of SwiNOG #26 as sponsor, please get in touch with us. (swinog-core at swinog.ch). For more informations go to: http://www.swinog.ch/sponsor kind regards, Michel Renfer SwiNOG Core-Team

1 0

Save the Date: SwiNOG #26
by Michel Renfer 11 Feb '13

11 Feb '13

Hi all! SwiNOG#26 --> save the date: 23rd may 2013. details will follow (date, time, registration, etc.). cheers, michel

1 0

Perl Courses and Conference
by Tobias Oetiker 08 Feb '13

08 Feb '13

Perl Users! In March, we will have two great Perl events in Switzerland. a) damian conway will be here again, teaching 2 brand new classes and his Advanced Technical Presentation Techniques tutorial where he shows how to give great talks. http://blogs.perl.org/users/damian_conway/2013/02/new-classes-premiering-in… b) On March 22nd the first Swiss Perl Workshop will be held in Bern. www.perl-workshop.ch cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi(a)oetiker.ch ++41 62 775 9902 / sb: -9900

1 0

Carrier Grade NAT – A Look at the Tradeoffs
by Fabian Wenk 07 Feb '13

07 Feb '13

Hello I just stumbled over the article "Carrier Grade NAT – A Look at the Tradeoffs" [1] (from Owen DeLong, Hurricane Electric) at Data Center Knowledge. I hope this helps to speed up the deployment of IPv6. [1] http://www.datacenterknowledge.com/archives/2013/02/06/carrier-grade-nat-a-… bye Fabian

2 1

Cablecom Home to London via USA
by Stephan Wolf 06 Feb '13

06 Feb '13

hello, since longer I have seen, that UPC is routing Cablecom Home connetions via US to London: Tracing route to 82.129.64.250 over a maximum of 30 hops 2 46 ms 68 ms 52 ms 77-56-176-1.dclient.hispeed.ch [77.56.176.1] 3 58 ms 58 ms 43 ms 217-168-58-101.static.cablecom.ch[217.168.58.101] 4 139 ms 140 ms 145 ms 84.116.211.22 5 149 ms 145 ms 140 ms 84.116.204.225 6 163 ms 171 ms 171 ms fr-par02a-rd1-gi-15-0-0.aorta.net[84.116.130.213] 7 147 ms 155 ms 163 ms 84-116-130-61.aorta.net [84.116.130.61] 8 167 ms 135 ms 165 ms 84.116.134.66 9 203 ms 233 ms 179 ms te-4-1.car3.Washington1.Level3.net[4.79.168.201] 10 147 ms 149 ms 145 ms ae-2-70.edge3.Washington4.Level3.net[4.69.149.82] 11 152 ms 144 ms 147 ms Cogent-level3-1x10G.washington.Level3.net[4.68.63.174] 12 158 ms 149 ms 171 ms te0-5-0-2.mpd22.dca01.atlas.cogentco.com[154.54.2.41] 13 167 ms 150 ms 143 ms te0-2-0-2.mpd22.jfk02.atlas.cogentco.com[154.54.5.49] 14 243 ms 254 ms 246 ms te0-2-0-2.mpd22.lon13.atlas.cogentco.com[154.54.42.54] 15 218 ms 223 ms 237 ms te0-3-0-6.ccr22.lon01.atlas.cogentco.com[154.54.74.61] 16 253 ms 240 ms 232 ms te2-1.ccr01.lon18.atlas.cogentco.com[154.54.61.214] 17 231 ms 246 ms 251 ms 149.14.8.34 18 227 ms 241 ms 230 ms 82.129.64.250 which causes high latencies via all other providers in CH which we have tried out, incl. and swissix, we have much better connections / less latency. also all our ISP's in germany have good connections only UPC lames - that sucks ;-( may someone of cablecom can check this, and contact me offlist ? thanks in advance stephan

7 13

Lost connection with MTA of Yahoo
by Jonathan Jeanneret 31 Jan '13

31 Jan '13

Hello, Since a few weeks, we've a problem when we send e-mail to MTA of Yahoo (yahoo.com or yahoo.fr) The log in our postfix server are: Jan 25 09:27:37 emailfrontal1 postfix/error[12384]: 19128F857F: to=<patrickjallut(a)yahoo.fr>, relay=none, delay=164344, delays=164344/0/0/0.03, dsn=4.4.2, status=deferred (delivery temporarily suspended: lost connection with mx-eu.mail.am0.yahoodns.net[77.238.184.241] while sending end of data -- message may be sent more than once) Jan 25 09:28:00 emailfrontal1 postfix/smtp[12670]: DAC59F88F9: to=<bzwahlenmattei(a)yahoo.com>, relay=mta5.am0.yahoodns.net[66.94.237.139]:25, delay=260738, delays=260715/0.01/12/11, dsn=4.4.2, status=deferred (lost connection with mta5.am0.yahoodns.net[66.94.237.139] while sending end of data -- message may be sent more than once) When we try a telnet connection it works but the sessions is closed after 5 sec: telnet mx-eu.mail.am0.yahoodns.net 25 Trying 77.238.184.241... Connected to mx-eu.mail.am0.yahoodns.net (77.238.184.241). Escape character is '^]'. 220 ********************************************************* We don't see any packet loss between yahoo and us. Is anyone have seen this problem? Can someone from Yahoo contact me offlist? Thanks for your help. Regards Jonathan -- Jonathan Jeanneret IP Systems Engineer Service Industriels Lausanne Citycable - www.citycable.ch jonathan.jeanneret(a)citycable.ch Phone: +41 21 315 96 40 Mobile: +41 79 506 28 57

3 2

Swisscom / Bluewin SMTP Servers changed?
by Jean-Pierre Schwickerath 31 Jan '13

31 Jan '13

Hi guys I get reports from customers sending their outgoing mail through smtp.swisscomdata.ch stating their mail is bounce due to SPF violation. It seems the IPs of the mailservers processing those messages have changed recently. Is there anyone from Swisscom mailserver team who could provide me with a list of IP of outgoing SMTP servers used to relay mail sent to smtp.swisscomdata.ch? It appears that IP ranges 46.14.34.0/24 and 46.14.97.0/24 are involved. I'd like to update the SPF declarations for those customers... 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/

5 4

SwiNOG-BE117 - Beer Event 117 @ Rolli's Steakhouse, Kloten / ZH
by Steven Glogger 29 Jan '13

29 Jan '13

Dear SwiNOGers, So, after having fondue last time - almost vegetarian - , we need to compansate some meat-requirements... steak time! Details for the next event: ----------------------------------------------- Event: SwiNOG-BE117 - Beer Event 117 When? Monday, 4th February 2013 18:30 Where? Rolli's Steakhouse, Kloten Gerbegasse 9, 8302 Kloten http://www.rollis-steakhouse.ch (GoogleMaps Link: http://goo.gl/maps/XouXp) !! Please sign up if you're really coming - because the seats are limited! !! ----------------------------------------------- Registration: Start: Monday, 28th January 2013 - 18:00 Stop: Sunday, 3rd February 2013 - 12:00 Reg-URL: http://swinog.be/ ----------------------------------------------- Since we have to make reservations, I need to know who's coming and who not. If you can't attend and you're registered please inform me ASAP (+41 79 277 92 35). greetings -Steven

1 0

Re: [swinog] Outbound Spam Filtering
by Gregory Agerba 25 Jan '13

25 Jan '13

Hi Jeroen, Let's not start this email security discussion by being focused on the bottom line or by being cynical and say some network will not care. We all know that out there, that shouldn’t stop legitimate providers from getting their act together. Let’s keep rational and positive. Personally, I have enough resources available for protecting my network regardless of a technology or a vendor, so I do not want to take the problem by assuming how much money do I have to put on the table. The thing is, relying on a proprietary (fictional) protection appliance which filters SMTP at will, based on unknown decisions factors is probably not the way to solve issues and is probably not future-proof as the spammers tend to have a few smartass and they have their own ecosystems for acquiring new spam technology. However, if some do work brilliantly, with very little false-negative/false-positive overheads, why not give them a chance. Getting back to the business, let me describe the goal of my previous message and the current deployments we have to cover such problems. I do not talk about DPI deployment and I am solely trying to solve abused-SMTP usage. The ultimate goal here is to protect IP reputation of servers. I do not want to filter dial-in, DSL, 3G network, but a Hosting network where the SMTP server will accept authentified customers to send their emails as long as they have proper credentials. Let me describe what I call a spam in this case, because the word spam holds multiple definitions and multiple usages and hardly get everybody to agree on its meaning. To me a spam is a message which is unsolicited, by opposition to a one-to-one, one-to-many or a newsletter communications, which may or may not be wanted by the recipients, but assuming the double opt-in was done correctly, this is different and it requires administrative handling rather than technical handling. In my case, I refer to customers who get their accounts compromised (either POP/IMAP and SMTP) in their email clients such as Outlook, Thunderbird or their Web Account (FTP, HTTP) with either some malicious piece of code on their computers or compromised self-made or well-known un-updated, compromised CMS such as Joomla or home-made poorly programmed scripts. We have two types of customers. Professional customers who know what they are doing. This kind of customer has no outgoing spam issue. They add a specific tag to their outgoing email, their emails are relayed to a smarthost which strips the header and do a few tricks such as DKIM signing and ultimately relay the message into the Internet. We can assume they send clean emails, unless somebody don’t want to receive them, but we handle this by Feedback Loop and that happens with a ratio of 1:200000. In addition, these customers usually have good security measures in place and we rarely see Trojan-infected hosts within their network. For the latter, we rate-limit the number of email they can send per hour (on some hosts) we look at the type of return we get in the incoming logs and we correlate sudden bursts of outbound message and NDR. Often we can quickly workout compromised accounts and we can identify the script, by looking at the source URI of the script or the SMTP- authenticated account which we reset the password and call the customer or wait for the call. This is usually not a rocket science and it requires a lot babysitting and don’t always prevent the arm of the being RBL. It is actually way harder to protect regular, simple, customer sending an email with his email client than protecting scripts and mass-mailing customers. Now anybody who dealt with an Outgoing Spam attack have seen that spammers are not always subtle and they just try to flood any address usually within aol, gmail and hotmail with low-quality spam to help solve impotence. Shall we just provide free blue pills to just solve the issue, or are they cheaper ways to get these behaviours to trigger some mechanism that pause/drop and give a chance to resume the mailing or just drop it dead? I am not against a system which is not perfect but which can be influenced by the administrators to not reproduce mistakes. Maybe somebody has more insights to share at this point. If somebody does, they are welcome most welcome. Cheers, Gregory On 25 January 2013 12:08, Jeroen Massar <jeroen(a)massar.ch> wrote: > On 2013-01-25 11:47, Gregory Agerba wrote: > > > > Hi everybody, > > > > > > This is a call to all ISPs and Hosters which operates shared or > > private environments where outbound spam is an issue. > > > > > > > > My goal here is not to collect selfishly as many possibilities for > > myself, but to collect them and see how they can be tested, > > implemented and documented to effectively (try to) eradicate spam. If > > they tend to work better than the one I am currently working on, I > > will put together a small presentation and share the outcome. > > Maybe the best first question is then: what are you working on? > > The next question are: > - how much money do you have to burn? > - what type of network do are you looking at? > DSL / Cable / GPRS/UMTS/EDGE / etc > do devices get static IPs / dynamic IPs / NAT/CGN? > do you have logs of which IP is at which customer etc > - how do you keep in contact with your customers/users? > - what are your other constraints? > > > Everybody wants to shift the spam outside of his network > > I think you mean that you want to not want to allow spam to go outside > of your network and that you want to catch it before it leaves? > > > > and everybody knows it is easier to filter inbound spam. > > Why? Spam is spam, if you can filter it outbound you can filter it > inbound. The only thing you need to do for outbound is to force > everything through the filter and that is where the nastyness comes. > > Instead of filtering you could also have a proper and quick abuse setup, > hence the "how do you keep in contact" above. > > > It is in the interest of > > all networks and the public to effectively work and implement these > > solutions. > > Unfortunately that is where a major problem lies: not all networks care. > > There are lots of networks that do not care at all, they get paid and > that is what they care about. > > Also, the larger your operation (eg, think the size of a > Cablecom/Swisscom) the more costly it is to stop and resolve spam from > leaving your network, either because one has to force those customers > through a filter/rate-limit setup or because contacting them all is costly. > > Note that are residential ISPs who set up walled-garden approaches, thus > at first strike mail the customer, second strike call the customer, > third strike put them in a walled garden so they get a nice webpage > telling them how bad they are. > > But depending on the contract they have you might not be able to pull > that off, also VoIP can be an issue when you block them that way. > > Oh, and when you force them through a SMTP filter it is very nice to > actually tell that to your customers, something that for instance > Swisscom still has not done and it is still impossible to find that they > are do, there is www.swisscom.ch/p25/ but that contains no details > whatsoever nor have they actually informed customers that they where > changing their internet connectivity to a filtered type. > > Let alone wondering what the heck they imply with > > "Aside from the spam filter for all Bluewin e-mail accounts, Swisscom > has started operating an additional spam filter on the DSL network. This > filter now also checks e-mail from free e-mail providers such as GMX, > Google Mail and Hotmail if the e-mail is sent from a Swisscom connection." > > Does that mean they sniff port 80 and 443 too so they can filter > GMX/Gmail/Hotmail or do they just mean port 25 (likely, but not sure) > > "As a result of the introduction of the new spam filter, e-mail that is > sent with SMTP authentication via port 25 can no longer be sent." > > Intercepting IP traffic is such a bad precedence for an ISP (because, > then they can also do that to other ports/protocols/IPs etc) and the > question of course also still is if that is even LEGAL in Switzerland... > > > > At the end of the research, I will get in touch with every contributor > > which had a concept, an idea or a working solution and see if and how > > they want to be credited within the document. To avoid useless noise, > > I will suggest sending me your suggestions off-list. > > It would be nice if you would start with explaining what you already > have, as then people can add to that. > > Greets, > Jeroen > > >

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog