Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Matthias Leisi]

I think Markus misses the main point of the OP. The question of the OP is not 
whether SPF is a good or bad idea in general.

The question is whether its reasonable to add a blacklisting entry for the 
server IP if you receive a single mail with a non-matching SPF record (ie, 
server with IP a.b.c.d not covered by the SPF for foo.com ). 

My take on this is that this blacklisting behaviour is entirely unreasonable. 

And I agree that it’s questionable why anyone should use a list with such 
unreasonable listing practices (apart from their extortion practices). 
Unfortunately the burden is first shifted not onto the admins responsible for 
such stupid decisions, but on the sending party who must wade through massive 
layers of ignorance and denial.

— Matthias

> Am 08.10.2020 um 09:14 schrieb Markus Wild :
> 
> Hello Urs,
> 
> My take on your problem is the following:
> - SPF is bad and breaks mail delivery, don't use it. But, if someone defines 
> SPF records, and they thus declare they
>  want to shoot themselves into their feet, by all means, I encourage to block 
> mails failing SPF, because that's what
>  domain owners who define SPF records ask for.
> - everyone can setup blocking lists defining the oddest criteria for when an 
> entry gets added. Someone in charge of a
>  mailserver can decide based on his criteria, and his alone, what mails he 
> wants to receive and what mail to reject.
>  He can use whatever resources he wants, including bogus lists such as 
> uceprotect. But, it would be prudent to inform
>  yourself about what exactly you enable before you do so...
> - now, if someone deploys antispam gateways such as those from Sophos, and 
> decides to just click "enable all block
>  lists" or however that menu looks like, and with this enables lists such as 
> uceprotect, then that person just cut
>  their company off from a lot of valid mail. If he wanted to do that, it's 
> his decision, but usually it helps to teach
>  those admins about the errors of their ways, instead of blaming the list 
> provider.
> - I personally consider uceprotect to be a rogue list with utopian views on 
> how mail service works. Their unlist policy
>  could be considered extortion, but the really responsible party is whoever 
> enables such a list on their servers.
> 
> just my personal views:)
> 
> Markus
> 
> 
> ___
> 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] SSL Certs question

[Matthias Leisi]

> I still find it funny that Digicert allows "Org Validated" (OV) certs to be 
> issued there. That is one of the few business cases that is left (e.g for 
> bare IP SSL certificates)

And it may make sense for S/MIME certs (even though „LE for S/MIME“ is on the 
horizon, see RFC 8823).

— Matthias
> 
> Greets,
> Jeroen
> 
> 
> 
> ___
> 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] Geldspielgesetz: 404 COMLOT renamed to GESPA? (or did they get hacked!?)

[Matthias Leisi]

> Still of course, no official word about this change...
> 
> Guess that fixing things is easier than communicating :)

And the list is still hilariously stupid.

It contains interwetten1.com  through 
interwetten10.com , but not interwetten10.com 
 through interwetten24.com 
, which all exist (at least in DNS). Many similar 
schemes in the list.

— Matthias


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

Re: [swinog] Bluewin MX - mail-fwd.mx.hostcenter.com

[Matthias Leisi]

> SMAIL SMTP-Send MX = "mail-fwd.mx.hostcenter.com." SMTP = "mhs.ch" From =
> "[EMAIL PROTECTED]" To = "" Failed !
>
> SMTP-Error = "451 Exhausted MX records for domain "

Seen here as well for a handful of domains, but not all transactions
through mail-fwd.mx.hostcenter.com are to be affected. First occurrence
here is 20060206 12:39:49

-- Matthias


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

[swinog] Out-of-Office Policies?

[Matthias Leisi]

Hi there,

I'm trying to gather arguments to stop the Out-of-Office notification 
nonsense. I know the technical arguments against OoO and other forms of 
auto-responders, but I'm interested to learn how different organisations 
are handling it.


If you don't want to answer publicly, please respond to me directly 
([EMAIL PROTECTED] - remember that the Swinog list overrides my 
Reply-To: header). I will respect any requests for anonymous handling, 
but I will send a summary to the list.


You may also answer in verbose form instead of using the questionnaire 
below :)


My questions:

0. What kind of organisation are you answering for (eg for your ISP 
staff, for your ISP customers, for your company users etc.)? About how 
many users do you handle?


1. Does your organisation allow OoO to external recipients?

If you answer no to question 1, no further questions required :) If you 
answer yes, please continue below:


2. Do you have any restrictions as to when/how OoO notifications are sent?
 [ ] No restriction
 _or_
 [ ] No OoO to detected spam
 [ ] OoO only to senders in the user's address book
 [ ] Only to senders with matching SPF/DKIM/Sender-Id etc
 [ ] Other restriction:

3. Have you had any DNSBL listings due to OoO notifications?
   If yes, which DNSBLs?

4. How do you send out OoO notifications?
 [ ] No special handling
 [ ] Over a dedicated IP address

Thanks a lot for your contribution,
-- Matthias
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

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

[Matthias Leisi]

Hi all,

The subject says it all: do you know which providers support TLS (the
technology formerly known as SSL) for SMTP, POP and/or IMAP for their
residential or small-office dialup/broadband customers?

If you are a provider yourself and you do not offer it: Are there
particular reasons? Is it a conscious decision not to offer it or is it
that just nobody asked yet?

Thanks,
-- Matthias
___
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, ...)?

[Matthias Leisi]

Daniel Lorch wrote:

> > Are you sure? Isn't that exactly the point of asymmetric cryptography?
> > The way I see it, TLS and SSL work like this (analogous to PGP):

You're almost right.


> > 1. The client connects to the server and obtains the server's public
> >key. The public key is a mathematical recipe to encode (but not
> >decode) a message for a specific recipient.

ACK.

> > 2. Using this public key, the client encodes the message (cleartext ->
> >ciphertext). Now the interesting part is, that the client isn't able
> >to decode this cipher text he just encoded, because he doesn't have
> >the private key (that's why it is also necessary to always encrypt
> >PGP messages to yourself, otherwise you won't be able to read them
> >later on in your "sent" box).

SMTP/TLS does not encrypt individual messages - as it's name implies, it
works on the *transport* layer. And there, the public key exchange is
used to agree on a symmetric session key.

Btw., neither server nor client public keys would technically be
required; anonymous DH would work as well (although it would not make
much sense...).


> > I could now connect to the mail server, obtain the public key and
> > generate as many cleartext/ciphertext pairs as I want and I still would
> > not be able to guess the private key from that information.

Of course, known-plaintext, replay and similar attacks on TLS and SSL
are theoretically possible. However, I have not heard of practically
possible or generally successful attacks.

-- Matthias


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

Re: [swinog] Mail Server suggestions

[Matthias Leisi]

Mike Kellenberger wrote:

> Preferably it should run on windows (we're just not at home on the *nix
> platforms), have all it's config options in a sql database, provide
> anti-spam and anti-virus out of the box, have a feature-rich webmail
> client and be tailored for a small ISP.

Do you really need a Windows-based product? Maybe an appliance-style
mailserver would suit your needs better, regardless of what operating
system it runs?

No, I would not want to recommend a specific solution ;)

-- Matthias

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

Re: [swinog] Mail server - Unix

[Matthias Leisi]

Jeroen Massar wrote:

>> dns was not really questioned, but I would prefer djbdns
>> (+patches, again) or bind.
> 
> Patches, patches, patches. Bind9 is fine (and actually what I usually
> use) but pdns&nds are simply faster, thus for scalability I would go for
> those, then again it depends on ones needs.

Given the potentially high DNS traffic (all those xBL lookups), a
dedicated caching DNS resolver may make sense. Additionally, you should
consider running a local rbldnsd for mirrored zones (proxying from the
resolver to rbldnsd).


>>>  - amavis + clamav & Spamassassin using milter inline in postfix
>> Seem both to be just 'the standard antivir and antispam' solution
> 
> There is afaik nothing better, especially in combo with:

Detection rates of ClamAV are pretty low. If you want to advertise
"virus protection" as a feature, you may want to integrate at least one
additional scanner.

-- Matthias

-- 
http://www.dnswl.org/ - Protect against false positives

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

Re: AW: [swinog] Whitelist website

[Matthias Leisi]

> Of course, but you got the hostname wrong. It's http://dnswl.swinog.ch aka
> http://antispam.imp.ch/swinog-dnsrbl-whitelist
>
> But not only Swiss Mailservers, this would be a bit useless :-)

And of course there is also dnswl.org ;-) [Note that dnswl.org data also
includes the Swinog whitelist, updated (ir)regularly.]

-- Matthias (one of [EMAIL PROTECTED])


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

Re: AW: AW: AW: [swinog] Whitelist website

[Matthias Leisi]

Radek Mrskos wrote:

> Ok, but this is exactly what do not belongs to this list. *.mail.ru (many
> others also) is a spamer domain.
> If the postmaster of *.rr.com, *.net.br, *.com.br calls you to enter his
> ranges, will you enter it?

194.67.23.0/24 does not equal the full set of *.mail.ru hostnames.

Similarly, dnswl.org contains three /24s for uol.com.br (see
http://www.dnswl.org/search.pl?s=3633). Now this is not a statement that
uol.com.br is all nice and cosy, but it's a statement of the fact that
the postmaster for uol.com.br told us that these are the ranges for the
mailservers (and we verified that using eg senderbase.org).

Since such ranges are usually not as trustworthy as /32s of
well-respected mailserver operators, dnswl.org lists such ranges with a
score of "none"; for all practical reasons, this should translate into
"do not greylist, since there is most likely a legitimate mailserver at
the other end who will retry anyway".

Yes, whitelisting incurs the risk of missing some spam. But this risk is
usually lower than catching a non-spam in a spamfilter.

-- Matthias

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

Re: [swinog] dnswl.org ?

[Matthias Leisi]

Per Jessen wrote:

>> Since such ranges are usually not as trustworthy as /32s of
>> well-respected mailserver operators, dnswl.org lists such ranges with
>> a score of "none"; for all practical reasons, this should translate
>> into "do not greylist, since there is most likely a legitimate
>> mailserver at the other end who will retry anyway".
> 
> This sounds like a pretty good idea, but judging by the size of the
> rbldnsd file, it's not very popular?  Only 4317 entries. 

There is definitely room for growth ;-)

dnswl.org data grows through three methods:

1) Company/organisation/individual/... mail administrators telling us
about their outgoing mailservers: http://www.dnswl.org/request.shtml

2) Importing/joining whitelists of trusted(!) sources. Currently, this
includes Swinog, ABUSES[1], and a financial services company.

3) dnswl.org administrators finding "good" mailservers by themselves (eg
by looking at incoming log files, user feedback etc)

You are all welcome to help! dnswl.org heavily relies on the
collaborative effort -- instead of everybody maintaining their own
lists, we can as well join forces :)

As to the popularity (see http://www.dnswl.org/mrtg/):

There are currently DNS requests from more than 330 distinct /24s (which
is roughly equal to distinct sites using dnswl.org data).

We have detailled usage logs/stats from 4 out of 7 DNS servers for the
list.dnswl.org zone. These 4 servers handle an average of above 15'000
queries/minute.

That's both not very impressive, but I expect usage to grow considerably
as soon as SpamAssassin 3.2 is released (currently in RC1 status), which
will include dnswl.org-based rules by default.

-- Matthias

[1] http://www.rediris.es/abuses/eswl/en/

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

[swinog] Revised telecommunication law - disclosure regulation

[Matthias Leisi]

Hello all,

The revised swiss telecommunications law (SR 784.10) that came into
effect today contains a provision that directly affects swiss providers,
namely article 45 paragraph 2, which reads [1, 2, 3]:

> Art. 45 Abs. 2
> 2 Wer diese Daten zur Ermittlung missbräuchlich hergestellter Verbindungen 
> oder
> unlauterer Massenwerbung benötigt, kann von der Anbieterin von 
> Fernmeldediensten
> Auskunft über Namen und Adressen der anrufenden Anschlüsse verlangen.

I see two potential things happening:

1) Customers ask their *own* provider about the name of the responsible
spammer for the usual drivel of spam sent through open proxies, abused
feedback forms and the like -- which is clearly not what is intended by
this article, and something which is clearly not possible in most cases.

2) Some spam recipients may be clueful enough to find out the
responsible provider, and if this provider happens to be under swiss
jurisdiction, the provider must reveal the identity of the spammer to
the complainer.

I do not care too much about the first case (although it may bring quite
some additional work on the help desks), but I was wondering how you
plan to handle the second case.

In order to satisfy both this clause and the general privacy protection
law (SR 235), a provider would need to:

* Verify the complaint (ie, was it really spam according to the
definition in the law).

* Verify that he indeed can identify the responsible individual customer.

Both of these preconditions have their own difficulties.

* How should a provider determine whether what the recipient got was
actually spam, especially if it is not a clear-cut case?

* How does the provider make sure it's actually a spamming case and not
eg a fishing expedition by a stalker or the copyright mafia?

* How is the actual responsible customer securely identified, eg if it
is an abused web form? What should be done in the case of the "hacked
wireless" defense?

In short, I see a considerable amount of work and uncertainty for
Internet providers in Switzerland (both residential/broadband _and_
hosting providers), both from their own customers and external complaints.

What's your take on it?

-- Matthias

[1] German text: http://www.admin.ch/ch/d/ff/2006/3565.pdf
[2] French text: http://www.admin.ch/ch/f/ff/2006/3439.pdf
[3] Italian text: http://www.admin.ch/ch/i/ff/2006/3309.pdf
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Large IP Block at Akamai?

[Matthias Leisi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

| so it looks like some sort of problem between init7 and
| akamai after all

DNS lookups for akamaized content (example used: members.spamcop.net)
from a DNS server behind an Init7 DSL line (213.144.132.248/29) returns
80.67.84.74 and 80.67.84.83, both of which time out when connected on
port 80.

Forwarding DNS requests through another DNS server located at Metanet
(80.74.132.72/29) returns different IP addresses (212.243.221.208 and
212.243.221.214) which both work.

Traceroutes to 80.67.84.74/.83 time out at Akamai:

majestix:~ matthias$ traceroute 80.67.84.74
traceroute to 80.67.84.74 (80.67.84.74), 64 hops max, 40 byte packets
~ 1  router (192.168.1.254)  1.439 ms  1.069 ms  1.085 ms
~ 2  eth0.r1.mleisi.dsl.init7.net (213.144.132.249)  2.725 ms  2.645 ms
2.591 ms
~ 3  lo0.lns2.bbcs.init7.net (213.144.128.206)  8.108 ms  8.424 ms  8.019 ms
~ 4  r1.core.init7.net (213.144.128.1)  8.135 ms  8.331 ms  8.171 ms
~ 5  tix2-nap.netarch.akamai.com (194.42.48.48)  8.289 ms  8.659 ms
8.807 ms
~ 6  * * *

So it's most likely Akamai who has to fix things; affected would be
everybody who gets directed to 80.67.84. in the Akamai CDN.

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFHnvaLxbHw2nyi/okRAi6qAJ9H5xRMF3215pfYWkFjiEYPfeVMLACfYuiT
npo+eakMwdO6j9MXCfbJE+Y=
=pyaw
-END PGP SIGNATURE-
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] The truth about UCEPROTECT-Blocklists

[Matthias Leisi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Keel schrieb:

> [193.138.29.15]: 571 Access denied and blocklisted: 990 
> (V4.07-RULE-0901) Sorry your IP is blacklisted at 
> http://www.backscatterer.org/?ip=217.26.49.182
> 
> Sadly, [EMAIL PROTECTED] doesn't really exist, so the mailserver
> of [EMAIL PROTECTED] gets into the uceprotect blacklist. 
> 
> The point of this is of course, that EVERY ISP which has some customer
> which uses autoreply can be blacklisted. This is very bad. 

Which concerns backscatterer.org, and _not_ Uceprotect. Same
organisation behind, but different policies.

And yes, autoreplies are bad. This also includes out-of-office
notifications. If you allow them out to the Internet at large, you're
almost as bad as the next pill spammer.

An admin that still allows such autoreplies should be tarred and
feathered and  hunted out of the city. He/she has no business in running
a mailserver.

- -- Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFItdDVxbHw2nyi/okRAuR9AJkBFfcEqPKparoZxpjEt+M4UuLr8wCgydeK
AnG3wCrKBaxb9F4cW97j+jw=
=FyYx
-END PGP SIGNATURE-
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] The truth about UCEPROTECT-Blocklists

[Matthias Leisi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Peter Keel schrieb:

>> And yes, autoreplies are bad. This also includes out-of-office
>> notifications. If you allow them out to the Internet at large, you're
>> almost as bad as the next pill spammer.
> 
> Try to explain that to the users at large and _any_ management. 

"Do you want to send email, or do you want to send Out-of-Office replies?"

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFIt5h+xbHw2nyi/okRAnbSAKCZwq2vEHGbdkLWFdUjvHDoZlCkDQCfZgT/
XB5HpBEhEQrSdALcq8Dvuk0=
=r9AG
-END PGP SIGNATURE-
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Netclean - news

[Matthias Leisi]

Fredy Kuenzler schrieb:

> From
> http://www.blogg.ch/index.php?/archives/785-Netclean-Whitebox-effektive-Methode-gegen-Kinderpornografie-im-Netz.html
> 
>> Netclean Whitebox funktioniert zweistufig: 1. wird via BGP4 die Liste
>> der verdächtigen IP Adressen in die Routingtabelle eingepflegt. 
>> Derzeit sind das um die 450 IP Adressen. Traffic von diesen Websites 
>> wird auf die Whitebox umgeleitet. Auf dieser erfolgt 2. die DNS resp.
>> HTTP Inspection, und die Whitebox ist damit in der Lage, zwischen 
>> illegalem und harmlosen Inhalt zu unterscheiden, der sich zufällig an
>> der selben IP Adresse befindet.

So it works kind of like eg Arbor Networks' DDoS protection mechanism
(redirect some traffic using BGP, deep packet inspection after packet
reassembly), coupled with data from an "uncontrollable" source (which is
generally believed to be some sinister government agency infiltrated by
oppressive political regimes).

It's interesting it took so long for commercial products to appear for
the technically obvious solution.

It will be interesting to see how fast well-meaning politicians and
paranoid pseudo police-men will want to filter all that nasty illegal
music from the net. And how long it will be before such machinery is
mandatory for all ISPs.

The excuse that there is no technical solution is gone - it was a lie
all along the way, and most techies knew. Now it's time to face the
consequences.

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

Re: [swinog] Post from Canton de Vaud

[Matthias Leisi]

Oliver Bollisger schrieb:

> but what is the best method? blocking ip traffic to the site can also
> mean to block legitimate traffic to a shared hosting server!?

Filter the traffic for specific IPs/networks/etc (eg by playing some BGP
games) through transparent proxies and redirect "forbidden" traffic to a
suitable target (or /dev/null).

Yes, that is an engineering challenge, but feasible.

Yes, that is a legal challenge, but it can be done in ways compatible
with constitutional rights and contractual obligations.

Yes, that contradicts many fundamental principles of how many people
perceive the Internet, but that is a weak argument in public discussion.

Yes, judges from the canton of Vaud seem to be specifically incompetent
and impertinent, but this can not be corrected by whining on a techie
mailing list.

Note that I'm far from endorsing or supporting such decisions, but that
I'm just asking for more effective ways to unmask the short-sightedness
of the judges orders.

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

[swinog] Fwd: Imminent closure of SORBS.

[Matthias Leisi]

For those of you running some anti-spam solution, watch out for SORBS
disappearing. Amongst other products, it's part of a default
SpamAssassin config.

-- Matthias

 Original-Nachricht 
Betreff: Imminent closure of SORBS.
Datum: Mon, 22 Jun 2009 12:26:39 +1000
Von: Michelle Sullivan 
Organisation: Spam and Open Relay Blocking System
Newsgruppen: news.admin.net-abuse.email

All,


Please feel free to forward this message to any other location/mailing list.


It comes with great sadness that I have to announce the imminent closure
of SORBS.  The University of Queensland have decided not to honor their
agreement with myself and SORBS and terminate the hosting contract.


I have been involved with institutions such as Griffith University
trying to arrange alternative hosting for SORBS, but as of 12 noon, 22nd
June 2009 no hosting has been acquired and therefore I have been forced
in to this announcement.  SORBS is officially "For Sale" should anyone
wish to purchase it as a going concern, but failing that and failing to
find alternative hosting for a 42RU rack in the Brisbane area of
Queensland Australia SORBS will be shutting down permanently in 28 days,
on 20th July 2009 at 12 noon.


This announcement will be replicated on the main SORBS website at the
earliest opportunity.


For information about the possible purchase of SORBS, the source code,
data, hosts etc, I maybe contacted at miche...@sorbs.net, telephone +61
414 861 744.


For any hosting suggestions/provision, please be aware that the 42RU
space is a requirement at the moment, and the service cannot be made
into a smaller rackspace without a lot of new hardware, virtual hosting
is just not possible.  The SORBS service services over 30 billion DNS
queries per day, and has a number of database servers with fast disk to
cope with the requirements.


Thank you for all your support over the years,


Michelle Sullivan
(Previously known as Matthew Sullivan)

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

Re: [swinog] Vorratsdatenspeicherung

[Matthias Leisi]

2009/7/12 Ihsan Dogan :

> Das würde aber schon fast nach einer Initiative schreien. Ging das
> eigentlich durch den Nationalrat?

Ähm, BÜPF/VÜPF sind ganz normal durch die Gesetzgebungsmaschinerie
gegangen. Hier geht es im Kern um Art. 5 Abs. 2 BÜPF
(http://www.admin.ch/ch/d/sr/780_1/a5.html):

| Die Auskünfte [können] auch sechs Monate rückwirkend angeordnet werden.

Das "Büchlein" ist die Umsetzung/Konkretisierung dieser Bestimmung.
Interessante Lektüre dazu ist auch Art. 23-27 VÜPF
(http://www.admin.ch/ch/d/sr/780_11/).

-- Matthias

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

Re: [swinog] swinog Digest, Vol 60, Issue 1

[Matthias Leisi]

Things should be back to normal.

-- Matthias

Am 04.01.10 21:24, schrieb robert.guentensper...@swisscom.com:
> Hi
> 
> We're investigating.
> 
> Cheers
> Günti
>  
> 
> -Original Message-
> From: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] 
> On Behalf Of supp...@hightechbits.com
> Sent: Monday, January 04, 2010 9:20 PM
> To: swinog@lists.swinog.ch
> Subject: Re: [swinog] swinog Digest, Vol 60, Issue 1
> 
> here same problem, bluewin is death
> 
> bluewin dns
> 195.186.1.110
> 195.186.4.110
> 
> kind regards mark
> 
> 
> -Ursprüngliche Nachricht-
> Von: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch]
> Im Auftrag von swinog-requ...@lists.swinog.ch
> Gesendet: Montag, 4. Januar 2010 21:07
> An: swinog@lists.swinog.ch
> Betreff: swinog Digest, Vol 60, Issue 1
> 
> Send swinog mailing list submissions to
>   swinog@lists.swinog.ch
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
> or, via email, send a message with subject or body 'help' to
>   swinog-requ...@lists.swinog.ch
> 
> You can reach the person managing the list at
>   swinog-ow...@lists.swinog.ch
> 
> When replying, please edit your Subject line so it is more specific than "Re: 
> Contents of swinog digest..."
> 
> 
> Today's Topics:
> 
>1. Bluewin DNS problems (Benjamin Schlageter)
>2. Re: Bluewin DNS problems (Flavio Tischhauser)
>3. Re: Bluewin DNS problems (Umberto Annino)
>4. Re: Bluewin DNS problems (Adrian Ulrich)
>5. Re: Bluewin DNS problems (Simon Leins)
>6. Re: Bluewin DNS problems (Benjamin Schlageter)
>7. routing quirks with IP-MAN (Marc SCHAEFER)
>8. Re: Bluewin DNS problems (Romain Bourdy)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 04 Jan 2010 20:16:14 +0100
> From: Benjamin Schlageter 
> Subject: [swinog] Bluewin DNS problems
> To: 
> Message-ID: 
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi
> 
> Anybody knows something about big DNS troubles with Bluewin ADSL/VDSL?
> As I saw, my router can?t resolve any domains... Lucky I got some other dns 
> servers =)
> 
> Cheers,
> Benjamin
> -- next part --
> An HTML attachment was scrubbed...
> URL:
>  nt-0001.htm>
> 
> --
> 
> Message: 2
> Date: Mon, 4 Jan 2010 20:37:03 +0100
> From: Flavio Tischhauser 
> Subject: Re: [swinog] Bluewin DNS problems
> To: Benjamin Schlageter 
> Cc: SWINOG 
> Message-ID:
>   <9bb210121001041137sc5835f3v55035b859e007...@mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
> 
> On Mon, Jan 4, 2010 at 20:16, Benjamin Schlageter 
> wrote:
>> Anybody knows something about big DNS troubles with Bluewin ADSL/VDSL?
>> As I saw, my router can?t resolve any domains... Lucky I got some 
>> other
> dns servers =)
>>
> 
> Same here, also receiving IMs from other swisscom customers telling me that 
> "their internet is broken".
> 
> regards
> 
> Flavio
> 
> 
> 
> --
> 
> Message: 3
> Date: Mon, 04 Jan 2010 20:37:25 +0100
> From: "Umberto Annino" 
> Subject: Re: [swinog] Bluewin DNS problems
> To: swinog@lists.swinog.ch
> Message-ID: <20100104193725.146...@gmx.net>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> I don't KNOW anything about it, but I am experiencing the same here, since 
> about one hour. Some sites respond well, others not or only very shaky or 
> partial.
> 
> DNS query time between 500-700ms.
> 
> I particularly like how bluewin is capable of presenting me a NICE and 
> easy-to-find status page of their service - NOT. stone age or what?
> 
> regards,
> Umbi
> 
>  Original-Nachricht 
>> Datum: Mon, 04 Jan 2010 20:16:14 +0100
>> Von: Benjamin Schlageter 
>> An: swinog@lists.swinog.ch
>> Betreff: [swinog] Bluewin DNS problems
> 
>> Hi
>>
>> Anybody knows something about big DNS troubles with Bluewin ADSL/VDSL?
>> As I saw, my router can?t resolve any domains... Lucky I got some 
>> other dns servers =)
>>
>> Cheers,
>> Benjamin
> 
> 
> 
> --
> 
> Message: 4
> Date: Mon, 4 Jan 2010 20:40:53 +0100
> From: Adrian Ulrich 
> Subject: Re: [swinog] Bluewin DNS problems
> To: swinog@lists.swinog.ch
> Message-ID: <20100104194054.0d0308...@echelon.blinkenlights.ch>
> Content-Type: text/plain; charset=US-ASCII
> 
>> Anybody knows something about big DNS troubles with Bluewin ADSL/VDSL?
> 
> No: Bluewin-DNS is fine for me. But i had some ADSL problems on 2-3. Jan:
> I had about ~30% packet loss with any (?) gateway in 195.186.252.0/24.
> 
> Re-Connecting until i got a gateway in the 253-range fixed the problem for me
> 
> Regards,
>  Adrian
> 
> 
> 
> --
>  RFC 1925:
>(11) Every old idea will be proposed again with a different name and
> a different presentation, regardless of whe

Re: [swinog] Swinog DNSRBL Whitelist

[Matthias Leisi]

2010/1/26 Mike Kellenberger :

> The server in question was 194.11.148.23 (outmail43.swisscom.com).
>
> Or does anyone have a list of swisscom outmail servers?

dnswl.org has: http://www.dnswl.org/search.pl?s=194.11.148.23

-- Matthias


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

[swinog] Change of dnswl.org operating model

[Matthias Leisi]

Hi,

As announced earlier, dnswl.org will change it's operating model.
"Heavy users" (defined as those doing > 100'000 queries/24 hours on
the public nameservers) and vendors of anti-spam products and services
will need a paid subscription.

We are now ready to implement the model and will gradually start to
enforce it. Since we do not know the current users (all we have are
IPs and sometimes hostnames), we will also need to "cut off" users if
our attempts at identifying and notifying them fail.

The "cut off" may have two of effects: 1) rsync suddenly stops working
2) queries on the public nameservers are refused. We may be able to
reinstate access on a case by case basis.

As usual, we can be reached at admins/at/dnswl.org (or
office/at/dnswl.org for direct access to the people handling the
subscriptions). All details are available from http://www.dnswl.org/

-- Matthias


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

[swinog] Fwd: [dns-operations] Advisory — D-root is changing its IPv4 address on the 3rd of January.

[Matthias Leisi]

-- Forwarded message --
From: Jason Castonguay 
Date: Thu, Dec 13, 2012 at 11:54 PM
Subject: [dns-operations] Advisory — D-root is changing its IPv4 address on
the 3rd of January.
To: casto...@umd.edu


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Advisory — D-root is changing its IPv4 address on the 3rd of January.


This is advance notice that there is a scheduled change to the IPv4
address for one of the authorities listed for the DNS root zone and
the .ARPA TLD. The change is to D.ROOT-SERVERS.NET, which is
administered by the University of Maryland.

The new IPv4 address for this authority is 199.7.91.13

The current IPv6 address for this authority is  2001:500:2d::d and it
will continue to remain unchanged.

This change is anticipated to be implemented in the root zone on 3
January 2013, however the new address is currently operational. It
will replace the previous IP address of 128.8.10.90 (also once known
as TERP.UMD.EDU).

We encourage operators of DNS infrastructure to update any references
to the old IP address, and replace it with the new address. In
particular, many DNS resolvers have a DNS root “hints” file. This
should be updated with the new IP address.

New hints files will be available at the following URLs once the
change has been formally executed:

http://www.internic.net/domain/named.root

http://www.internic.net/domain/named.cache

The old address will continue to work for at least six months after
the transition, but will ultimately be retired from service.

- --
Jason Castonguay

Network Integration Software Engineer
Division of Information Technology
University of Maryland
College Park, MD 20742
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDKXLEACgkQA5NiLuECHn4lRQCgoOlYQhq+kXk2Az3nPeN1hUfz
0e4AoKCwp0cLpABJFc/7RV5E/ecfWwoJ
=ktnM
-END PGP SIGNATURE-
___
dns-operations mailing list
dns-operati...@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[swinog] ip-plus.net Nameservers dead?

[Matthias Leisi via swinog]

It looks like ip-plus.net nameservers are dead. ns1 times out, ns2 has no IP.

I expect some fallout…

— Matthias
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Sicherheit von SS7 - mit Schweiz-Bezug

[Matthias Leisi via swinog]

(Resend von der richtigen Absender-Adresse)


https://www.haaretz.com/israel-news/security-aviation/2023-05-10/ty-article-magazine/.premium/global-surveillance-the-secretive-swiss-dealer-enabling-israeli-spy-firms/0188-0005-dc7e-a3fe-22cdf290

The Secretive Swiss Dealer Enabling Israeli Spy Firms

(…)

It leads from the Americas to Africa to South-East Asia, but also to Basel, a 
mediaeval town on the banks of the Rhine and the unassuming home of Andreas 
Fink, a Swiss telecom expert whose unusual skills have placed him at the centre 
of this industry.

(…)

reveal how Fink's systems have served as a conduit for probing and attacking 
phone networks across the globe

(…)

When contacted by this investigation, Fink admitted to working with companies 
and “legally entitled government agencies” as a provider of surveillance 
services.

(…)

Fink's request to Robert was for "SS7 access" and "a bunch of global titles". 
In other words, he wanted a list of phone numbers, belonging to Robert's phone 
company, which could be used to send queries to other networks in other 
countries. 

(…)

-- 
Matthias Leisi
Katzenrütistrasse 68, 8153 Rümlang
Mobile +41 79 377 04 43
matth...@leisi.net <mailto:matth...@leisi.net>___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch