[swinog] Re: Swiss Domain Security Report Q3 2022
Hi swinog / init7
Thanks @adrian for the report and @daniel for pointing out the NXDOMAIN issue.
Maybe this is well-known, but I would like to point out that this swinog list
has a problem with DKIM and SPF.
1) DKIM: not valid ("message has been altered") because of the email forwarding
without re-signing
2) SPF: wrong record
> Authentication-Results: opendkim.logging.ch;
> dkim=fail (2048-bit key) reason="fail (message has been altered)"
> header.d=switch.ch header.b=qiNTrxHE
> Received-SPF: permerror (lists.swinog.ch: Unknown mechanism type 'redirect'
> in 'v=spf1' record) receiver=mx3.logging.ch; identity=mailfrom;
> envelope-from="swinog-boun...@lists.swinog.ch"; helo=vmaill01.sys.init7.net;
> client-ip=82.197.188.230
> Received: from vmaill01.sys.init7.net (vmaill01.sys.init7.net
> [82.197.188.230])
SPF misconfiguration:
> dig +short lists.swinog.ch txt
> "v=spf1 redirect:init7.net"
The correct record should read as:
> "v=spf1 redirect=init7.net"
See https://www.rfc-editor.org/rfc/rfc7208#section-6.1
While 2) would be an easy fix, 1) might involve some more work.
My 2 cents - Gruass, Franco
On 08.06.23 07:42, Daniel Stirnimann via swinog wrote:
> Hi Adrian,
>
>
> On 07.06.23 21:33, Adrian Ulrich via swinog wrote:
>>> I'm pretty surprised that of the 1.7M domains with an MX record, only 57%
>>> have DKIM
>>
>> I don't see how one could reliability gather this data from DNS:
>>
>> DKIM allows you to specify a selector in the header of the mail: This mail
>> for example will use 'sx1' as the selector (check out the header ;-) ):
>>
>>> $ dig +short txt sx1._domainkey.blinkenlights.ch
>>> "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC[]
>>
>> But without ever receiving a mail from me: how would you know?
>>
>> You could try to send a query for '_domainkey.blinkenlights.ch' and you MAY
>> receive a NOERROR reply - but that's not guaranteed: My DNS will just return
>> an NXDOMAIN:
>>
>>> $ dig txt _domainkey.blinkenlights.ch|grep status:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10153
>
>
> Your nameserver breaks https://www.rfc-editor.org/rfc/rfc8020
>
> This document states clearly that when a DNS resolver receives a
> response with a response code of NXDOMAIN, it means that the domain
> name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
>
> Daniel
> ___
> swinog mailing list -- swinog@lists.swinog.ch
> To unsubscribe send an email to swinog-le...@lists.swinog.ch
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] Re: DNSSEC auto-disabled by SWITCH on some .ch domains?
Luckily I have some historic .ch zone data laying around, so I did a quick analysis of the number of ALG-7 / ALG-5 / DS-1 domains, please find the numbers below. Seems the wipe-out has been performed in chunks, maybe by registrar. SWITCH willing to share some info? Also interesing to see that the number of DS-1 hashes in the .ch zone file is raising again. All coming from hosttech. Though by now it seems these are not published anymore. Gruass, Franco DATEALG-7 ALG-5 DS-1 = = 2023-04-01530 41 59645 2023-04-02529 41 59627 2023-04-03528 41 59466 2023-04-04527 41 59443 2023-04-05527 41 59427 2023-04-06527 41 59394 2023-04-07526 41 59383 2023-04-08526 41 59354 2023-04-09524 41 59332 2023-04-10524 41 59315 2023-04-11524 41 59274 2023-04-12278 28 58756 2023-04-13279 28 58733 2023-04-14272 22 57566 2023-04-15269 22 57543 2023-04-16269 22 57529 2023-04-17269 22 57504 2023-04-18 72 19309 2023-04-19 10 7133 2023-04-20 10 7135 2023-04-21 10 7147 2023-04-22 7 4 88 2023-04-23 7 4 92 2023-04-24 7 4 92 2023-04-25 7 4 91 2023-04-26 7 4 97 2023-04-27 7 4 98 2023-04-28 0 0 0 2023-04-29 0 0 0 2023-04-30 0 0 1 2023-05-01 0 0 1 2023-05-02 0 0 5 caroule-music.ch. 3600IN DS 7321 8 1 FF2BCD11DBBEB58B15CE581AC4D0B4F0FA7B5AC8 caroulemusic.ch.3600IN DS 49924 8 1 B23CB635433B6DF5893FE94BD7F27B91DED2FD3C datalawyer.ch. 3600IN DS 49765 8 1 73CD7B42648847E43C2CF6A1E4F2680F8C0C20A4 digilawyer.ch. 3600IN DS 13045 8 1 A5E02D7FF95BACE907F93197A23E45CB65DFF838 workforceag.ch. 3600IN DS 49996 8 1 98B42F52FE01CB6E593CB463C11E3C602C6F2BB1 On 01.05.23 17:33, Franco Hug wrote: > Thanks Daniel for your helpful answers. Yes, CDS is also something I always > wanted to try, but as usual: no hard pressure, no time... ;-) > > Benoît Panizzon wrote: >> From their point of view, my 'algo 5' .ch domains have still DNSSEC active > > Basically the same behavior I had with my 'algo 7' domains (infomaniak). > >> but deleting DS or disabling DNSSEC hangs forever and upon reloading my old >> algo 5 keys are back. > > I did not even try to delete/disable DNSSEC, I was just able to update the > existing record (key/algo/hash). Then the update towards the registry was > carried out immediately, seems the old values do not matter then. Cannot > tell whether that works with Gandi though. > > Maybe option #3 besides the nerd and normal answers and worth a try? > > Gruass, Franco > ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] DNSSEC auto-disabled by SWITCH on some .ch domains?
Hey SWINOGgers, I noticed that DNSSEC was somehow auto-disabled at registry level for some .ch domains I am responsible for. For these domains, no DS records are published anymore in the .ch zone, dnsviz shows a broken chain of trust. However, registrar data still shows that DNSSEC is enabled, but the registry (SWITCH) says it is not... Is this a known problem? Seems not all DNSSEC protected .ch domains are affected, which leads me to the suspicion that it might have to do with the algorithm being used. Did SWITCH turn off older algorithms, e.g. algo 7 (RSASHA1-NSEC3-SHA1)? Did I miss an announcement? Random example, e.g. gkb.ch (notably a bank...) > dig +short @dns1.inventx.ch gkb.ch dnskey > 256 3 7 AwEAAdYydDZyd5M3UGS5b4Yv6qlIO5eOSwskJ/DQjiRO0as59ZG6hMDJ > VseqslJMTwghdiCrd/sicWvDOszK6Cuqye0+ZEm9tfG6gxgWWmzpSmXQ > KDHRG1iV8UF0KSOciFAPp4qRe083KPXu2ChXkTUSAa/iRCcZdFJK2M6l c7Gjjj55 > 257 3 7 AwEAAbQv5Whc+cna1IbtESB+Pwx+8eP5jfbjhuqiFuU/18qUckR9NxT7 > KUCT8GDlRTsGYmuKxcMITvH510CgGOA/6TORaB4iIXRnACmfiiku25/B > NHmNJd58ymZ/ED17smVJ4ou77/rhxW+/0Q1iVIAOcY8EblWq3EabepYz > E6CY9Vh/RTh2mvSl80h8nZyFotsEwN0LIlc/Pi0qGmy7iTOBqtVsbFVm > gssn/2c7IMCA8N2aaP1it8Qi+3DDGDh3N8HSEIVk+nrgQtsqQaLOFPGQ > Q0ezahQO6oVGKG4XAHw+2XaZQ3UT0sTcFj3ZVKCcGE4Ddoa3J/gqLQh7 aA44cVIQx+s= > > dig +short @a.nic.ch gkb.ch ds > > -> no DS record Working example with algorithm 13 (ECDSA Curve P-256 with SHA-256): > dig +short @ns2.switch.ch switch.ch dnskey > 257 3 13 keJOWxnKOCymNa0sPpwp/ioeyvgrXjY9hu8KxWdaxlMFukxquKVLdt2J > 5KxGOpmIZZbOXRALfG78FnDsE/k8EQ== > 256 3 13 YOf+TLHGeDBL0q6DSpE4vE2ub8RUvniew7xYkZJHocU6je7Ww/MfUeHf > B1LEDpFNFloYHFBvWD92gu5MT2ZJ1A== > 256 3 13 twHlL7CfhxPadzuRi3wRxEDs+3i/oe9W3heRKiP8CALwpexBZYCjMJ2w > Z403h9dJ/iA7CzCTSmvePLGdJ4cIzQ== > > dig +short @a.nic.ch switch.ch ds > 32265 13 2 8A865736961D246F99D6111BCA060E69908380FD5545D799F21E4652 DA60A17C Could anybody shed some light on this? Thx & Gruass, Franco ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] Re: DNSSEC auto-disabled by SWITCH on some .ch domains?
Thanks Daniel for your helpful answers. Yes, CDS is also something I always wanted to try, but as usual: no hard pressure, no time... ;-) Benoît Panizzon wrote: > From their point of view, my 'algo 5' .ch domains have still DNSSEC active Basically the same behavior I had with my 'algo 7' domains (infomaniak). > but deleting DS or disabling DNSSEC hangs forever and upon reloading my old > algo 5 keys are back. I did not even try to delete/disable DNSSEC, I was just able to update the existing record (key/algo/hash). Then the update towards the registry was carried out immediately, seems the old values do not matter then. Cannot tell whether that works with Gandi though. Maybe option #3 besides the nerd and normal answers and worth a try? Gruass, Franco On 01.05.23 17:11, Benoît Panizzon via swinog wrote: > Hi Daniel > >> The nerd answer is that you can use Automated DNSSEC Provisioning [1] >> to enable DNSSEC. This also sends an EPP poll message to your >> registrar to update locally cached state information about a domain >> name. > > Yes, trying to understand, how I correctly get rid of my old RRSIG > entries without shooting myself in the foot, I came across this whole > new dnssec-policy and automatic publishing CDS records via Bind. > > Not sure if I have yet fully understood the mechanics. But I have > tentatively set it up now and I'll see, if this somehow, by the magic > of the internet, caused my DS entries to get refreshed. > ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] Re: DNSSEC auto-disabled by SWITCH on some .ch domains?
Hi all, Thanks for your replies, you basically backed my work assumption concerning deprecated algorithms, good to know. However, this raises some questions about the chosen proceeding of "just wiping" algo 5/7 and digest 1 DS records from the .ch zone... Affected domain holders should and could have been informed (by whoever...), I am pretty sure there are more affected .ch/.li domains out there, with its domain holders not being aware that their DNSSEC protection is currently turned off. Didn't have this problem with other tld's so far. Would be interesting to see a chart similar to this one: https://www.nic.ch/de/statistics/dnssec/ which shows the different algorithms in use. Marcus Jaeger wrote: > To the partners at least, in October 2022 informing them that anything > containing digest-type 1 and/or key algorithm 5 oder 7 are no longer > supported and will be deleted. > This was done last week and digest-type 2 and key algorithm 13 should be used. Well, as an end user I am not a "partner" in the sense of the registry/registrar agreement, so I never received any communication about this proceeding. Who would be liable and paying for a possible damage? Where damage in the best case would be junked or non deliverable emails, services not working as expected, additional admin work (you/me), etc. I guess either the registry (SWITCH) for "just doing this", or the registrars for not passing on this information to their customers... This would be a funny law suit... ;-) > Since end of January 2023 you could not use them anymore. Probably valid for new DNSSEC activations, had no effect on pre-existing algo 5/7 domains. John Howard wrote: > Not sure if/how it relates to this situation, but it’s notable that the > DNSSEC key signing ceremony was a couple of days ago? > > https://www.iana.org/dnssec/ceremonies/49 > > I don’t see any deprecations but maybe someone needs an update somewhere? Probably unrelated coincidence, but thanks for sharing, interesting 3.5h ceremony, didn't watch it in full though... ;-) Jeroen Massar wrote: > Alg 7 is ancient and deprecated... Technically, agreed. I am bearing this in my head since months or even years that I should "eventually" change this. Eventually now changed to immediately... Administratively, there is a slight difference between ancient/deprecated and disabled/forbidden. Reminds me of RFC-2119 (MAY, MUST, MUST NOT, etc). Rhetoric question, what is better: a domain signed with a deprecated algorithm, or a non-signed domain from which the holder thinks it is signed? Benoît Panizzon wrote: > Guess I have to read: https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html Since DNSSEC was disabled, I guess you can't do a key rollover. Just start over... > I wonder why my registrar never noticed me he would delete my DS records > disabling DNSSEC on my domains. I guess it was the registry that wiped the DS records, not your registrar. At least my registrar's GUI still showed a nice all-green DNSSEC overview with the wiped DS records still in place... Thanks & have a nice and secure week ;-) Gruass, Franco On 01.05.23 11:50, Marcus J via swinog wrote: > G'day > > just saw something was missing in my reply. > It should say : digest-type 2 and key algorithm 13 should be used. > > cheers > > Marcus > > ___ > swinog mailing list -- swinog@lists.swinog.ch > To unsubscribe send an email to swinog-le...@lists.swinog.ch ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] DNSSEC auto-disabled by SWITCH on some .ch domains?
Hey SWINOGgers, I noticed that DNSSEC was somehow auto-disabled at registry level for some .ch domains I am responsible for. For these domains, no DS records are published anymore in the .ch zone, dnsviz shows a broken chain of trust. However, registrar data still shows that DNSSEC is enabled, but the registry (SWITCH) says it is not... Is this a known problem? Seems not all DNSSEC protected .ch domains are affected, which leads me to the suspicion that it might have to do with the algorithm being used. Did SWITCH turn off older algorithms, e.g. algo 7 (RSASHA1-NSEC3-SHA1)? Did I miss an announcement? Random example, e.g. gkb.ch (notably a bank...) > dig +short @dns1.inventx.ch gkb.ch dnskey > 256 3 7 AwEAAdYydDZyd5M3UGS5b4Yv6qlIO5eOSwskJ/DQjiRO0as59ZG6hMDJ > VseqslJMTwghdiCrd/sicWvDOszK6Cuqye0+ZEm9tfG6gxgWWmzpSmXQ > KDHRG1iV8UF0KSOciFAPp4qRe083KPXu2ChXkTUSAa/iRCcZdFJK2M6l c7Gjjj55 > 257 3 7 AwEAAbQv5Whc+cna1IbtESB+Pwx+8eP5jfbjhuqiFuU/18qUckR9NxT7 > KUCT8GDlRTsGYmuKxcMITvH510CgGOA/6TORaB4iIXRnACmfiiku25/B > NHmNJd58ymZ/ED17smVJ4ou77/rhxW+/0Q1iVIAOcY8EblWq3EabepYz > E6CY9Vh/RTh2mvSl80h8nZyFotsEwN0LIlc/Pi0qGmy7iTOBqtVsbFVm > gssn/2c7IMCA8N2aaP1it8Qi+3DDGDh3N8HSEIVk+nrgQtsqQaLOFPGQ > Q0ezahQO6oVGKG4XAHw+2XaZQ3UT0sTcFj3ZVKCcGE4Ddoa3J/gqLQh7 aA44cVIQx+s= > > dig +short @a.nic.ch gkb.ch ds > > -> no DS record Working example with algorithm 13 (ECDSA Curve P-256 with SHA-256): > dig +short @ns2.switch.ch switch.ch dnskey > 257 3 13 keJOWxnKOCymNa0sPpwp/ioeyvgrXjY9hu8KxWdaxlMFukxquKVLdt2J > 5KxGOpmIZZbOXRALfG78FnDsE/k8EQ== > 256 3 13 YOf+TLHGeDBL0q6DSpE4vE2ub8RUvniew7xYkZJHocU6je7Ww/MfUeHf > B1LEDpFNFloYHFBvWD92gu5MT2ZJ1A== > 256 3 13 twHlL7CfhxPadzuRi3wRxEDs+3i/oe9W3heRKiP8CALwpexBZYCjMJ2w > Z403h9dJ/iA7CzCTSmvePLGdJ4cIzQ== > > dig +short @a.nic.ch switch.ch ds > 32265 13 2 8A865736961D246F99D6111BCA060E69908380FD5545D799F21E4652 DA60A17C Could anybody shed some light on this? Thx & Gruass, Franco ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
Re: [swinog] Coop.ch geoblocking?
Hey guys, On 21.06.21 21:35, Serge Droz wrote: > Hi all > > It seems there is a SWINOG member who should clean his computer. > > Happy hunting > Serge I don't think so. Root problem is the SWINOG mailman archive which happens to be very open: http://lists.swinog.ch/public/swinog/2021-June/thread.html http://lists.swinog.ch/public/swinog/2021-June/007518.html Even for a stupid crawler it is quite easy to collect your email address from there. That's the reason why I don't like to post to this list: it automatically makes me a future victim of SWINOG external SPAM. I once posted something to this list (must be 10 years ago). It took less than a week for the first SPAM mails to arrive. In fact, anyone who ever posted to this list is subject to direct spam. SWINOG should really re-think its list archive... On 22.06.21 08:58, Jeroen Massar wrote: > I suggest using a mailhost that has proper spam filtering, considering it is > trivial to identify > that the sending host is not properly configured, why bother accepting mail > from it? That's not enough. In first place, the SWINOG contributors should be protected from being crawled. -> SWINOG homework On 21.06.21 23:42, Jeroen Massar wrote: > Full headers would be rather useful to determine the real origin of that > message... Full ACK. Preferrably in the correct order. So for the sake of completeness, let's do the header dance: > X-Authenticated-Sender: cloudserver2.webbossuk.com: in3d...@in3days.org > X-Get-Message-Sender-Via: cloudserver2.webbossuk.com: authenticated_id: > in3d...@in3days.org > Received: from cloudserver2.webbossuk.com (cloudserver2.webbossuk.com > [95.172.31.250]) (using TLSv1.2 with cipher > ECDHE-RSA-AES256-GCM-SHA384 > (256/256 bits)) (No client certificate requested) by > mailin025.protonmail.ch (Postfix) with ESMTPS id 4G7yKH3NF6z9vNPW for > ; Mon, 21 Jun 2021 18:11:47 + (UTC) > Received: from [136.35.59.161] (port=45371 helo=in3days.org) by > cloudserver2.webbossuk.com with esmtpsa (TLS1.2) tls > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (Exim 4.93) (envelope-from > ) id 1lvNEU-00069P-CD for s.d...@protonmail.ch; > Mon, > 21 Jun 2021 17:57:10 +0100 Email coming from 136-35-59-161.googlefiber.net [136.35.59.161] sent through cloudserver2.webbossuk.com (esmtpsa -> authenticated) which happens to host in3days.org. So most probably a hacked web hosting account. However, this does not help much, since the root cause is the SWINOG mailman archive. You will get spam from all over the world. Gruass, Franco ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] What blacklists does @bluewin.ch use
Hi Benoît, I don't know - but I do find this in their email headers: X-Bluewin-Spam: Cloudmark -> https://www.cloudmark.com At the bottom of that page you can even find the Swisscom logo. My 2 cents, hope they help! Gruass, Franco On 10/31/17 15:08, Benoit Panizzon wrote: Hello List A Mailserver from a business customer of ours is blacklisted @ bluewin. The Error Message from Bluewin MXes directing to the removal site: https://www.swisscom.ch/en/res/hilfe/ip-blacklist.html Our customer has requested removal via this form, no success. Our customer has contacted bluewin and opened a trouble ticket. He got the information that his ISP (us) should take care to remove his IP from the blacklists, but is not getting any information about which blacklists. http://multirbl.valli.org Blacklisted: 0 We are at a loss. Does anyone know what kind of blacklists bluewin uses? Kind regards -Benoît Panizzon- ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Reject von hotmail.com
Hoi zaema, Ich beobachte das gleiche Verhalten mit contabo.de, aus dem Netz 178.238.224.0/22, evtl. gar 178.238.224.0/20 ... > DE-GIGA-HOSTING-20100728 178.238.224.0 - 178.238.239.255 > CONTABO 178.238.224.0 - 178.238.227.255 Da scheint das ganze Netz auf einer Migro$oft Blacklist gelandet zu sein. > 550 SC-001 (BAY004-MC3F37) Unfortunately, messages from 178.238.227.40 > weren't sent. Please contact your > Internet service provider since part of their network is on our block list. > You can also refer your > provider to http://mail.live.com/mail/troubleshooting.aspx#errors. Bei den einschlaegig bekannten blacklists ist das Netz auf jeden Fall nicht gelistet. In der Tat hatte ich selbst innerhalb der letzten 3 Monate 1x ein Spam-Mail aus diesem Netz erhalten. Eigentlich nichts Aussergewoehnliches, hin und wieder flutscht halt mal was durch bei diesen grossen Providern. Dass deswegen ein ganzes Netz gelistet wird, und somit auch Unschuldige betroffen sind, ist aergerlich. Umso mehr, weil nicht wirklich klar ist, was man genau tun muss, um das Problem zu beheben. Deshalb habe ich als quick-fix die IP-Adresse des outgoing MX angepasst. D.h. ich habe das Problem nicht geloest, sondern umschifft... Gruass, Franco - Original Message - From: "David Schweikert" <da...@schweikert.ch> To: "Klaus Ethgen" <klaus+swi...@ethgen.de> Cc: swinog@lists.swinog.ch Sent: Friday, March 18, 2016 7:51:42 AM Subject: Re: [swinog] Reject von hotmail.com Hoi Klaus, On Fri, Mar 18, 2016 at 06:36:52 +0100, Klaus Ethgen wrote: > zur Zeit bekomme ich meine Mails an hotmail.com-Adressen mit der Meldung > "550 SC-001 (COL004-MC2F18) Unfortunately, messages from 5.9.7.51 > weren't +sent. Please contact your Internet service provider since part > of their network is on our block list. You can +also refer your provider > to http://mail.live.com/mail/troubleshooting.aspx#errors.; abgelehnt. Mein privater Server bei Hetzner wird auch schon seit einigen Monaten von hotmail.com, live.com, etc. blockiert. Ich glaube, dass ganze Netblocks von Hetzner auf automatische Blacklisten gelandet sind. Meine Vermutung ist, dass Hetzner ein spammer-hosting Problem hat. Google hat uebrigens auf "mailop" (eine Mailing-Liste fuer Mail Hoster) gesagt, dass es bei ihnen auch passieren kann, dass ganze netblocks blockiert werden: https://www.mail-archive.com/mailop@mailop.org/msg01042.html Vielleicht koenntest du mit IPv6 versuchen. Oder auch ein Versuchswert ist DMARC. Oder die Mails ueber eine andere IP routen... Gruss David ___ 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] Has Bluewin a DNS Problem
Hi Xaver, I had a similar problem when I set up the mail server on my virtual server and wanted to send mail to domains that are hosted by zoneedit.com. After searching a while, I think this is the way how it works: Step 1: == Bluewin does a reverse DNS lookup on your IP (195.141.232.78), which returns the following: # nslookup 195.141.232.78 ;; Truncated, retrying in TCP mode. Server: www.multipop.ch. Address:195.141.232.253#53 78.232.141.195.in-addr.arpa name = mailhost.aa795.ch. 78.232.141.195.in-addr.arpa name = mailhost.aerni.net. 78.232.141.195.in-addr.arpa name = mailhost.bar16.ch. 78.232.141.195.in-addr.arpa name = mailhost.sysop.ch. 78.232.141.195.in-addr.arpa name = mailhost.zingg.org. 78.232.141.195.in-addr.arpa name = mailhost.satshop.cc. 78.232.141.195.in-addr.arpa name = mailhost.aquacare.ch. 78.232.141.195.in-addr.arpa name = mailhost.glaettli.cc. 78.232.141.195.in-addr.arpa name = mailhost.multipop.ch. 78.232.141.195.in-addr.arpa name = mailhost.satshops.ch. 78.232.141.195.in-addr.arpa name = mailhost.spacebbs.ch. 78.232.141.195.in-addr.arpa name = mailhost.amigaland.ch. 78.232.141.195.in-addr.arpa name = mailhost.augsauger.ch. 78.232.141.195.in-addr.arpa name = mailhost.begegnung.ch. 78.232.141.195.in-addr.arpa name = mailhost.satvision.ch. 78.232.141.195.in-addr.arpa name = mailhost.hackernews.ch.ch. 78.232.141.195.in-addr.arpa name = mailhost.natel-news.ch. 78.232.141.195.in-addr.arpa name = mailhost.satanlagen.ch. 78.232.141.195.in-addr.arpa name = mailhost.satantennen.ch. 78.232.141.195.in-addr.arpa name = mailhost.wiso-schoch.ch. 78.232.141.195.in-addr.arpa name = mailhost.xariffusion.ch. 78.232.141.195.in-addr.arpa name = mailhost.sat-receiver.ch. 78.232.141.195.in-addr.arpa name = mailhost.estherundpetr.ch. 78.232.141.195.in-addr.arpa name = mailhost.luisenstrasse.ch. 78.232.141.195.in-addr.arpa name = mailhost.arthurandersen.ch. 78.232.141.195.in-addr.arpa name = mailhost.elektronik-news.ch. 78.232.141.195.in-addr.arpa name = mailhost.zuerichsee-gastro.ch. 78.232.141.195.in-addr.arpa name = mailhost.pop.ch. 78.232.141.195.in-addr.arpa name = mailhost.rtv.ch. 78.232.141.195.in-addr.arpa name = mailhost.dsng.ch. Step 2: == Bluewin does a normal forward DNS lookup, using the result from the above query. The forward (A) query has to match your IP address, otherwise Bluewin will complain about the PTR record. However, the above query returned more than one value, so I am not sure which host is used for the lookup - I guess that just the first host is taken. Since the order is random, you cannot say anything reliable about which host will be used for the lookup. Maybe it even fails directly if the response is not unique - I don't know. When I tried the lookup the first time, mailhost.aquacare.ch was used for the query. However, mailhost.aquacare.ch does not exist (even the domain does not exist), so the lookup fails and rightly so Bluewin complains about your PTR record. I think the purpose of this reverse and forward DNS lookup procedure is to prevent spam, since most spam comes from hacked machines (mostly from dynamic IP address ranges) which do not have correct PTR records - just as it is the case with your machine ;-) Gruass, Franco Adrian Ulrich wrote: Good Morning, Is your source ip 195.141.232.78 ? Regards, Adrian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog Xaver Aerni wrote: Our System receive ex. This MSG The original message was received at Tue, 25 Mar 2008 16:20:47 +0100 from localhost [127.0.0.1] - Transcript of session follows - ... while talking to mxbw.bluewin.ch.: 451 No thanks. (How about PTR records?) ... while talking to mxzhh.bluewin.ch.: QUIT 451 No thanks. (How about PTR records?) ... while talking to mxzhb.bluewin.ch.: QUIT 451 No thanks. (How about PTR records?) [EMAIL PROTECTED]... Deferred: 451 No thanks. (How about PTR records?) Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old ** Xaver Aerni Zürichstrasse 10a 8340 Hinwil Tel. 001 707 361 68 39 ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
