[swinog] Re: bluewein.ch - automatic spamtrap?
On Fri, Jul 15, 2022 at 7:33 AM Claudio Kuenzler wrote: > Datawire is off the hooks. Turning around the wheel and going North, > towards the lands of Hetzner. > The MX-Record of bluwein.ch resolves to sendmailtoserver.bluwein.ch, which sometimes answers with a A record pointing to Hetzner, sometimes with a different A record pointing to I-Netpartner in Germany. I didn't receive a confirmation that they forwarded my complaint/contact request to their customer. From I-Netpartner however I received a call today. The domain "bluwein.ch" is indeed registered to the owners of the UCEProtect DNSBL and has been for many years. According to the infos I obtained, UCEProtect sometimes buys previously used domains, turns off any MX record for one year and then switch on the MX records again. All received mail is then immediately flagged as spam because "only spam systems would send e-mails to a previously unavailable domain". Whether or not this domain is used for "catching typo errors" is speculation. I personally think the domain name is way too close to the widely used bluewin.ch domain. When I look at our relay, we see all kinds of typo errors relating to bluewin.ch, e.g. buewin.ch, bluwiin.ch and many more variations. We have now internally resolved this blacklisting problem by adjusting our mail relay's (Postfix) transport rule, bouncing all e-mails destined to bluwein.ch: # Do not send mails to the following domains bluwein.ch error:Admiral Ackbar knows this is a trap Maybe this solution comes in handy for others going down the same path. ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] Re: bluewein.ch - automatic spamtrap?
On Fri, Jul 15, 2022 at 7:15 AM Claudio Kuenzler wrote: > > Thanks for all the responses and ideas! > > So the research and journey has begun with Datawire. May it hopefully end > in success. I shall inform you all again, whether or not I've become wiser. > To prove how fast such a typo happens, take my e-mail as example. The spamtrap domain in question is actually "bluwein.ch" and not "bluewein.ch". :-/ Datawire is off the hooks. Turning around the wheel and going North, towards the lands of Hetzner. ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] Re: bluewein.ch - automatic spamtrap?
On Thu, Jul 14, 2022 at 5:26 PM Matias Meier wrote: > For me it looks like, that the domain ‘bluewein.ch’ is not in control of > Swisscom, but it is in control of the person who most likely also controls ‘ > ict-olten.ch’ and ‘cuida.ch’. > > You could try to contact Datawire AG, as the IP address of the > ‘mailserver’ ‘mail.ict-olten.ch’ is hosted by them… maybe prepare a > message and ask them friendly to forward it to their customer. That would > be my approach. > Thanks for all the responses and ideas! So the research and journey has begun with Datawire. May it hopefully end in success. I shall inform you all again, whether or not I've become wiser. > ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] bluewein.ch - automatic spamtrap?
Hello list, We are seeing some "mean" behaviour when sending an e-mail to any e-mail address ending in @bluewein.ch. Note the difference between bluewin and bluewein... As soon as an e-mail is sent from our relay to this domain, we get listed on the UCEProtect-Level1 blocklist. Yes, we can discuss whether or not this is a serious blacklist, but some mail providers actually use this service and then block our legit e-mails. Now to this domain. On HTTP all seems in order, the domain is redirected to bluewin.ch. But SMTP points to a separate mail server: mail.ict-olten.ch. Behind ict-olten.ch seems to be nobody (no website, no other results so far after a bit of research). Does anyone here in the list have information about the behaviour of this domain and who is responsible for it? Obviously a typo "bluewein" instead of "bluewin" happens pretty fast when users are registering and it's already the second or third time within a month that we get blacklisted due to a typo from users. thanks for any hints and cheers, ck ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
Re: [swinog] bluewin & DNSNULL
Sorry about the last mail, my spam filter declared my outgoing mail as spam as well. This is what my mailserver detected when it analyzed your mail: 8.5 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist [URIs: m ail.f ink.o rg] Maybe Swisscom/Bluewin does kind of the same, just call it differently? Note I added some whitespaces into the domain. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] *****SPAM***** Re: *****SPAM***** bluewin & DNSNULL
Spam detection software, running on the system "mail01.infiniroot.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Not sure about the bluewin severs, but my server sent your mail immediately to spam because of this: 8.5 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist [URIs: mail.fink.org] Might be the same or related to this. Content analysis details: (7.6 points, 7.0 required) pts rule name description -- -- -1.0 ALL_TRUSTEDPassed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 URIBL_SBL_AContains URL's A record listed in the Spamhaus SBL blocklist [URIs: fink.org] 8.5 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist [URIs: fink.org] The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. --- Begin Message --- Not sure about the bluewin severs, but my server sent your mail immediately to spam because of this: 8.5 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist [URIs: mail.fink.org] Might be the same or related to this. --- End Message --- ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Swisscom -> AWS outage 10.10.2016 (via NTT)
Hello all, I'd like to know if anyone else experienced routing problems yesterday on October 10th 2016 from Swisscom networks to Amazon AWS (Ireland). We've had our server connections cut between 1400 and 1450. I'm pretty sure the problem was with NTT, which was the next hop after Swisscom. At 1450 someone (Swisscom or AWS?) changed the routing and the next hop after Swisscom changed to DTAG. Does anyone have more insights who "fixed" it yesterday? Swisscom only responded to our incident ticket that "Amazon uses loadbalancers and therefore several destination ip addresses" and "traceroute has changed since your screenshot" which is not helpful at all. Thanks in advance for any information. ck ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] E-Mail Hacks
Hi Mike A friend of mine unfortunately had a similar case with a Chinese partner firm. The e-mail correspondence was intercepted - I suspected a trojan in the Chinese firm (or simply an employee of that Chinese firm going rogue, who knows...). The forged mail was exactly as you describe it: The second e-mail stated, that the bank account information was changed. However in this case the forged mail clearly came from another e-mail, but it looked very close to the one from the Chinese partner. Unfortunately my friend didn't see it. He asked me to help investigate this as his e-mail account runs on a server I manage and from the mail logs I could show him that the forged mail came from another sender. Take a look at the mail headers and mail logs of the recipient server (if you can) to verify where the fraud mail came from. Compare the sending servers, the e-mail address itself can be easily changed as you may know. I am at this moment not aware of the current status of that case but I know police investigation (and also investigations on my friends Swiss bank) were ongoing. cheers, Claudio On Fri, Oct 7, 2016 at 2:46 PM, Mike Kellenberger < mike.kellenber...@escapenet.ch> wrote: > Hi all > > I might be slightly off-topic here, because it's not a network issue, but > it might be of interest to some of you anyway and maybe you've had > customers which were affected as well. > > I don't know if this ploy is new, but after having two customers affected > within one week, I suspect it is. > > The customer receives an e-mail with an invoice from his supplier, which > he trusts and has worked with in the past. Shortly after this e-mail he > receives another e-mail from the same sender and in the exact same layout > stating that the company has a new bank account and that this account > should be used. > > The second e-mail is forged of course. We haven't beeen able to find out > where the original mail gets captured (most likely on the suppliers client, > because in one case, more than one customer of the supplier was affected). > > The fraudulent bank account was in UK in both cases, in one case the > amount was around CHF 6K, where the UK authorities did not get active, in > the second case it was a 6 digit amount... That case is still ongoing. > > The fraudulent bank account was already closed again in both cases when > the customer realized that his transaction had gone to the wrong account > (usually after the supplier asked if the money had not been transferred > yet). > > > Have you had similar cases? > > > Regards, > > Mike > > -- > Mike Kellenberger | Escapenet GmbH > www.escapenet.ch > +41 52 235 0700/04 > Skype mikek70atwork > > > ___ > 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] anyone else problem contacting bluewin.ch SMTP Servers?
On Wed, Aug 28, 2013 at 9:35 AM, Michael Richter mrich...@sasag.ch wrote: mrichter@CL-LINUX-3OG-MR:~$ telnet mxzhh.bluewin.ch 25 Trying 195.186.227.50... Connected to mxzhh.bluewin.ch. Escape character is '^]'. 421 4.4.5 Service unavailable, concurrency limit reached. Connection closed by foreign host. Trying 195.186.227.50... telnet: connect to address 195.186.227.50: Connection refused telnet: Unable to connect to remote host This with all 3 MX: bluewin.ch.88INMX10 mxbw.bluewin.ch. bluewin.ch.88INMX42 mxzhb.bluewin.ch. bluewin.ch.88INMX42 mxzhh.bluewin.ch. I just wanted to verify this and the very first time it worked: # telnet mxzhh.bluewin.ch 25 Trying 195.186.227.50... Connected to mxzhh.bluewin.ch. Escape character is '^]'. 220 zhhdzmsp-mxin28.bluewin.ch ESMTP Service (Swisscom Schweiz AG) ready But right after I got the same error as you: # telnet mxzhh.bluewin.ch 25 Trying 195.186.227.50... Connected to mxzhh.bluewin.ch. Escape character is '^]'. 421 4.4.5 Service unavailable, concurrency limit reached. Connection closed by foreign host. But then again... # telnet mxbw.bluewin.ch 25 Trying 195.186.99.50... Connected to mxbw.bluewin.ch. Escape character is '^]'. 220 zhbdzmsp-mxin15.bluewin.ch ESMTP Service (Swisscom Schweiz AG) ready # telnet mxbw.bluewin.ch 25 Trying 195.186.99.50... telnet: Unable to connect to remote host: Connection refused # telnet mxzhb.bluewin.ch 25 Trying 195.186.99.50... Connected to mxzhb.bluewin.ch. Escape character is '^]'. 220 zhbdzmsp-mxin19.bluewin.ch ESMTP Service (Swisscom Schweiz AG) ready Seem to be very random problems: - 421 4.4.5 Service unavailable, concurrency limit reached. - Unable to connect to remote host: Connection refused - Sometimes connection works fine ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] bluewin mail feature
On Tue, Aug 14, 2012 at 6:49 PM, Fabian Wenk fab...@wenks.ch wrote: Hello Stefan On 14.08.2012 16:11, Stefan Rothenbuehler wrote: On 08/14/2012 03:42 PM, Tobias Oetiker wrote: occasionally we get mail bounces from bluewin that look like this: Jul 6 13:17:31 postfix/smtp[30166]: : to=x...@bluewin.ch, relay=mxbw.bluewin.ch[195.186.**99.50]:25, delay=2, delays=0.02/0/0.05/2, dsn=5.0.0, status=bounced (host mxbw.bluewin.ch[195.186.99.50] said: 551 551x...@bluewin.ch Account administratively disabled. Please try later (in reply to RCPT TO command)) Those mails are rejected as the recipients account has been administratively blocked. This can have various reasons which I'm not gonna list here. I do see a discrepancy here. The mail account is temporary closed, as you say and also the text Please try later does indicate. But the error 551 is a permanent error and the sending server will purge this e-mail from the queue and notify the original sender of the non-delivery. It would probably be a good idea to respond only with a 4xx error, which is temporary. So the sending server could queue the e-mail and try again later, without any interaction from the end user. Usually the sending mail server does notify the original sender, after delivery of the e-mail has failed for several hours. It then will try up to 5 days to deliver this e-mail, before the e-mail will be purged from the queue and the original sender being notified. +1 for that. I've had similar issues last week with e-mail forwardings to a bluewin address. My customer then thought the problem comes from my server when he received the non delivery mail (due to the 5xx error). After informing him, that the error message came from Swisscom/Bluewin he himself didn't know why Swisscom would (temporary?) block his account. To suggest to my client that he has to temporary remove his e-mail forwarding doesn't seem to be a smart solution to me... But sure, this depends on how long such accounts are administratively blocked. If it is only for a few days, then a 4xx error would be much friendlier, also to the affected Bluewin customer. If one of this customer is also subscribed to several mailing lists, then there is a very high chance, that he will be automatically unsubscribed from them as well. What is the reason anyway? Technical issues? Billing issues with the affected customer? Account administratively disabled could mean literally anything. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
