Re: [anti-abuse-wg] AS16019, vodafone.cz == idiots
Ronald, my two cents on this: > > http://www.openspf.net/Why?s=mfrom;id=rfg%40tristatelogic.com;ip=80.95.99.97;r=mail2.dkm.cz There are many SMTP relays in the world checking SPF record for the incoming mail and providing a diagnostics with openspf.net web. But unfortunately this website is down for almost two years and this diagnostics leads to nowhere. If someone is running a mail relay, then now is a good time to check its responses. -- Kind regards, Sergey Myasoedov > On 12 Dec 2020, at 11:36, Ronald F. Guilmette wrote: > > Some days I am inclined to wonder how or why anything at all actually > works on this planet. I suspect that I am not alone, given that > Covid-19 has now exposed for all the world to see just how inept and > dysfunctional even so-called "first world" systems are at dealing > with anything that is even just a little bit out of the ordinary. > > Another case in point: AS16019 aka vodafone.cz, whose formally > declared abuse reporting address, as given in the WHOIS record > for the ASN, is ab...@vodafone.cz. Unfortunately, if you send > a copy of a spam that you have received from their network to that > address, you will get back something that may look vaguely like this: > > : host mail2.dkm.cz[62.24.64.36] said: 550 5.7.1 >: Recipient address rejected: Please see > > http://www.openspf.net/Why?s=mfrom;id=rfg%40tristatelogic.com;ip=80.95.99.97;r=mail2.dkm.cz > > So, the retorical question for the day is: Just how completely idiotic > does any given group of network operators have to be in order to be > unable to just simply operate a functioning email address for inbound > messages? > > I guess Vodafone is either too broke or too cheap to hire merely competent > people. > > It would be one thing if this was an impoverished third-world country > involved here, but it isn't. It's the Czech Republic. So what is their > excuse for this level of sheer incompetence? > > Does someone need to send a formal memo to Vodafone, explaining to them > about this thing called spam? > > And why are they even leaving port 25 outbound open on end-luser lines? > > > Regards, > rfg >
Re: [anti-abuse-wg] Spam from provider Timeweb/Russia AS9123 - and they just ignore me
Hi Martin, Why did you set "p=none" in your DMARC policy? Why not reject or quarantine? -- Sergey Monday, May 25, 2020, 4:09:14 PM, you wrote: > Hey everyone, > I have a conflict with a provider from Russia "Timeweb" AS9123. > It seems to be hosting a customer who sends spam and uses one of my domains > as sender. > I got the information via DMARC, RFC 7489 with several mails. > This provider has an abuse email address. After I contacted them, > they analyzed my domain, complained about the header of the > automatic DMARC e-mail from mail.ru, because there an internal > host distributes it and uses an internal IP address 10/8 according to RFC > 1918 and so on. > Apparently one does not want to do anything and requests one of > these e-mails classified as spam sent to @mail.ru. > But this is not provided for in the DMARC protocol, which the provider does > not 'believe’. > This means I continue to receive emails from Russia telling me > that my domain is being used by their host to send spam. And the > provider writes me many e-mails telling me that I have to provide > correct facts and that nothing else will be done. > Because DMARC emails are not facts and cannot be used as evidence. > Do you have any idea how to deal with this? > I have received 11 DMARC emails from mail.ru regarding this host. > I have attached last one here with header: > Return-Path: > Delivered-To: m...@mnin.de > Received: from mail.mnin.de ([]) > by mail.mnin.de with LMTP > id yedWJNMKx14sDAAAuS6XVA > (envelope-from ) > for ; Fri, 22 May 2020 01:12:19 +0200 > Received: from relay7.m.smailru.net (relay7.m.smailru.net [94.100.178.51]) > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) > (No client certificate requested) > by mail.mnin.de (Postcow) with ESMTPS id 6D59868509C > for ; Fri, 22 May 2020 01:12:18 +0200 (CEST) > DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; > d=corp.mail.ru; s=mail; > > h=Date:Message-ID:To:From:Subject:MIME-Version:Content-Type; > bh=DMqnfyeB+D0YjhIdtRipG66iEqaOVRHns+l07FJTLbw=; > > b=k6PdTMpn2SHfn7HO4jdOto6jxVRnOLsCsFLz0Lp87ytUyQL7ifwnze/LC/xQlDQ1hLpkHdM/sM8RFDgusUQYtL4e7/Zkmln4vsjgPvsW6go/YK7hvaeQBKMKgDSXqTlTXqm7BUyXOU4g9wByuAWUM0UpOM+3lrgHzm7d/Fil5IU=; > Received: from [10.161.4.115] (port=48176 helo=60) > by relay7.m.smailru.net with esmtp (envelope-from > ) > id 1jbuMI-0007Kr-2n > for m...@mnin.de; Fri, 22 May 2020 02:12:14 +0300 > Content-Type: multipart/mixed; > boundary="===1678280035031557895==" > MIME-Version: 1.0 > Subject: Report Domain: mnin.de; Submitter: Mail.Ru; > Report-ID: 25590927945792699841590019200 > From: dmarc_supp...@corp.mail.ru > To: m...@mnin.de > Message-ID: > Date: Fri, 22 May 2020 02:12:14 +0300 > Auto-Submitted: auto-generated > ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mnin.de; > s=dkim; t=1590102738; > > h=from:from:reply-to:subject:subject:date:date:message-id:message-id: > to:to:cc:mime-version:mime-version:content-type:content-type: > dkim-signature; > bh=DMqnfyeB+D0YjhIdtRipG66iEqaOVRHns+l07FJTLbw=; > > b=YpE4Z5u3l+mzLxsH+2Qbd39KekLCXa2jbbIrdnDxvgNFS6zvl4zKq33jQ/7fs5KkJEB0Xc > > VCRT+1keQ9x/+a0tp6IMMUKE1elcOp6LHbBzTXCZYcgylnhbmb/JrCgAUI67KzXJlLn4o4 > > pxToLIR5HD58dGeler0v2GTby5si8GUfczS2mM4QAvxJHDSZ8GqTE359H8HTmXUXGBQRb+ > > 0RVhhOzYxwmusEpWvuMcXYm4oZ7V+eKNuv12N5xCAbaWaqen37v1M53j0pu1vYoUSQBgOa > > dv3UgtOSdPxj8wVI5OzpY6ZVKtfSqyTXW5dV+8yfZUSe1Zpm/UPOO5eaqyUnpw== > ARC-Seal: i=1; s=dkim; d=mnin.de; t=1590102738; a=rsa-sha256; cv=none; > > b=keiIRdDt35e1bk6toEJdITgagC1CXQE81NoMoM8T19TBM9LFU4zudqRg73qPYgGkqvXqqI > > Te3Z+AC+CZp9bxfqIOrm2xSE8fNfZEKYhl5fB59sen9/m1rwiZznvvbNcBCJMpytYyDAbg > > l74M2uJVfvrUAoAbMF8dweJV/SANBC2K6eKs1r9nRu5DrCEcicWKNLxWbvZ7Q/TccUGgeZ > > VCyYvxqc0m5U7wZqK/32Sgf1EpWAjkXpC5eTMxH73FfrIkpPQa8v5ag6qKMP+GRk8B3GO1 > > eQxsci0l3eATOMFFeEAW/QkSB+ur5f2bPEraluEN5VD4iwWzd2tBGmbcT0ZKaw== > ARC-Authentication-Results: i=1; > mail.mnin.de; > dkim=pass header.d=corp.mail.ru header.s=mail header.b=k6PdTMpn; > spf=pass (mail.mnin.de: domain of > dmarc_supp...@corp.mail.ru designates 94.100.178.51 as permitted > sender) smtp.mailfrom=dmarc_supp...@corp.mail.ru > X-Last-TLS-Session-Version: TLSv1.2 > Authentication-Results: mail.mnin.de; > dkim=pass header.d=corp.mail.ru header.s=mail header.b=k6PdTMpn; > dmarc=pass (policy=reject) header.from=corp.mail.ru; > spf=pass (mail.mnin.de: domain of > dmarc_supp...@corp.mail.ru designates 94.100.178.51 as permitted > sender) smtp.mailfrom=dmarc_supp...@corp.mail.ru > --===1678280035031557895== > MIME-Version: 1.0 > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 > VGhpcyBpcyBhbiBhZ2dyZWdhdGUgcmVwb3J0IGZyb20gTWFpbC5SdS4= > --===1678280035031557895== > Content-Type: application/gzip > MIME-Version: 1.0 >
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Dear Jordi, > There are existing procedures for that in extreme cases. I think it's now obvious that existing procedures does not work. -- Sergey Friday, May 8, 2020, 1:20:45 PM, you wrote: JPMvaaw> However, I fully understand that the community prefer to do things in different steps. JPMvaaw> We initially asked for the abuse mailbox. JPMvaaw> Then we added a technical validation. JPMvaaw> Now I'm asking for a better validations and make sure that JPMvaaw> the reporting is feasible. I'm not asking to verify if you handle the abuse case or not. JPMvaaw> *AND* I'm not asking to take *new* actions. There are JPMvaaw> existing procedures for that in extreme cases. JPMvaaw> JPMvaaw> El 30/4/20 9:51, "anti-abuse-wg en nombre de Serge Droz via JPMvaaw> anti-abuse-wg" anti-abuse-wg@ripe.net> escribió: JPMvaaw> I do not disagree with this. JPMvaaw> Serge JPMvaaw> On 30.04.20 09:41, Hans-Martin Mosner wrote: JPMvaaw> > Am 30.04.20 um 02:58 schrieb Suresh Ramasubramanian: JPMvaaw> >> JPMvaaw> >> However, being in a fiduciary role - with IPv4 being traded like JPMvaaw> >> currency these days the description fits - RIPE NCC can’t not get JPMvaaw> >> involved. JPMvaaw> >> JPMvaaw> > ... JPMvaaw> >> NCC owes it to the rest of its membership and the internet community JPMvaaw> >> at large to take a more active role in this matter. JPMvaaw> >> JPMvaaw> > This. JPMvaaw> > JPMvaaw> > And as long as RIPE and/or NCC explicitly does not want to take action JPMvaaw> > when RIPE members don't handle abuse from their networks properly, the JPMvaaw> > whole issue of validating abuse mailbox addresses is moot. After all JPMvaaw> > discussion, the toothless compromise will be that there should be an JPMvaaw> > abuse mailbox, and FWIW it can be handled by Dave Null because nobody JPMvaaw> > will exert pressure on the resource holder to do anything else. JPMvaaw> > JPMvaaw> > Our problem on the receiving side of network abuse is not with the few JPMvaaw> > good-willing but technically challenged providers whose abuse mailbox JPMvaaw> > isn't working properly but with those large operators who don't give a JPMvaaw> > flying f about their customer's network abuse. JPMvaaw> > JPMvaaw> > Personally, I consider the anti-abuse WG a failure at this point. When I JPMvaaw> > joined I had hoped to see and possibly support constructive work towards JPMvaaw> > a reduction in network abuse, but apparently there are big players in JPMvaaw> > this game who are not interested in such a reduction as it would JPMvaaw> > undermine their "business". JPMvaaw> > JPMvaaw> > Cheers, JPMvaaw> > Hans-Martin JPMvaaw> > JPMvaaw> -- JPMvaaw> Dr. Serge Droz JPMvaaw> Chair of the FIRST Board of Directors JPMvaaw> https://www.first.org JPMvaaw> ** JPMvaaw> IPv4 is over JPMvaaw> Are you ready for the new Internet ? JPMvaaw> http://www.theipv6company.com JPMvaaw> The IPv6 Company JPMvaaw> This electronic message contains information which may be JPMvaaw> privileged or confidential. The information is intended to be JPMvaaw> for the exclusive use of the individual(s) named above and JPMvaaw> further non-explicilty authorized disclosure, copying, JPMvaaw> distribution or use of the contents of this information, even JPMvaaw> if partially, including attached files, is strictly JPMvaaw> prohibited and will be considered a criminal offense. If you JPMvaaw> are not the intended recipient be aware that any disclosure, JPMvaaw> copying, distribution or use of the contents of this JPMvaaw> information, even if partially, including attached files, is JPMvaaw> strictly prohibited, will be considered a criminal offense, JPMvaaw> so you must reply to the original sender to inform about this communication and delete it.
Re: [anti-abuse-wg] RIPE NCC Report: Law Enforcement Agency Requests 2019
Dear Maria, Thank you for this report. I think it's better to explain abbreviations like 'MLAT' as I google it and it wasn't too easy to find the meaning without RIPE NCC website. PS. MLAT stands for 'mutual legal assistance treaties' -- Sergey > On 25 Mar 2020, at 10:47, Maria Stafyla wrote: > > Dear colleagues, > > We have published a transparency report that details the nature > of the requests we received from Law Enforcement Agencies in 2019. > > You can find the report at: > https://www.ripe.net/publications/docs/ripe-740/ > > Kind regards, > > Maria Stafyla > Senior Legal Counsel > RIPE NCC > >
Re: [anti-abuse-wg] [routing-wg] An arrest in Russia
Hi Nikolas, Thank you for your explanation, I appreciate it. > On 2 Jan 2020, at 14:29, Nikolas Pediaditis wrote: > > With regards to implementing policies and procedures, we apply them as > equally and neutrally as possible, but we also consider it reasonable and > sensible to take extraordinary circumstances into account. On this occasion, > RIPE NCC Management reviewed a case in which new information had come to > light and it decided to act as it saw necessary and appropriate. I do believe that the extraordinary circumstances are when the ER department is involved in the process. But usually RIPE NCC don't perform the rollback of transfers. In the case we've seen, two members are still active, no M deal, but suddenly Ministry of foreign affairs got involved, crime investigation is ongoing... In the similar circumstances in Kazakhstan (2018-2019) the NCC decided not to make any statements in the court and didn't revert the transaction until the Supreme court made its decision. The unpredictability of the NCC's actions don't make the members happy. -- Kind regards, Sergey Myasoedov
Re: [anti-abuse-wg] [routing-wg] An arrest in Russia
Hi Marco, > Later, we received new information from both organisations about this > transfer. It was then followed by an official request in which both parties > asked us to revert the changes made to our registry and return the IP > addresses back to their previous holders. After an internal review, we > reverted the registration of the addresses. Can you give some more details on the fact that policy requirements for holding the resources for 24 months after the transfer was suspended? > While we cannot disclose more details publicly, we would like to emphasise > that we took this action within our mandate to maintain an up-to-date and > correct Internet number resource registry, and as a neutral and impartial > organisation. The last sentence proves that there are rules and there are rules. How the NCC can be a neutral organisation while policy isn't applied to all members in an equal manner? Thank you and have a happy holidays. -- Kind regards, Sergey Myasoedov > On 31 Dec 2019, at 09:28, Marco Schmidt wrote: > > Dear colleagues, > > We would like to provide some clarification on this case. > > Earlier this year, we transferred a large number of IP addresses from the > autonomous nonprofit organisation "Russian Scientific-Research Institute for > Public Networks” in the Russian Federation to the Reliable Communications > s.r.o in the Czech Republic. > This change was processed by the RIPE NCC in full compliance with RIPE > Policies and the RIPE NCC’s published procedures. > > Later, we received new information from both organisations about this > transfer. It was then followed by an official request in which both parties > asked us to revert the changes made to our registry and return the IP > addresses back to their previous holders. After an internal review, we > reverted the registration of the addresses. > > While we cannot disclose more details publicly, we would like to emphasise > that we took this action within our mandate to maintain an up-to-date and > correct Internet number resource registry, and as a neutral and impartial > organisation. > > Kind regards and Happy New Year, > > Marco Schmidt > Registration Services and Policy Development Assistant Manager > RIPE NCC > > > On 29/12/2019 06:45, Randy Bush wrote: >>> It would be nice if RIPE NCC could provide as part of its annual >>> report a list of incidents of this nature so we have an idea of how >>> wide-spread this is - or not. >> as i try not to indulge in schadenfreude, i don't have much use for this >> information. >> >> we spent some time in this space in rotterdam. the presos were well >> done, but not my cup of coffee. i am sure there were others who found >> it fascinating. i guess that's what makes the world go 'round. >> >> randy >> > >
Re: [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)
Support the withdrawal. -- Sergey Thursday, September 5, 2019, 6:31:28 PM, you wrote: >> I'd like to suggest to the chairs that this proposal be formally >> dropped. RB> please RB> randy
Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
Hello community, I strongly oppose to this proposal. The proposal gives a power for misuse to the RIR and does not protect members against setup. I believe this policy have nothing to do in RIPE. It's better to issue it as a BCP document or an informational RFC. -- Sergey Tuesday, March 19, 2019, 1:41:22 PM, you wrote: MS> Dear colleagues, MS> A new RIPE Policy proposal, 2019-03, "BGP Hijacking is a RIPE MS> Policy Violation", is now available for discussion. MS> The goal of this proposal is to define that BGP hijacking is not MS> accepted as normal practice within the RIPE NCC service region. MS> You can find the full proposal at: MS> https://www.ripe.net/participate/policies/proposals/2019-03 MS> As per the RIPE Policy Development Process (PDP), the purpose of MS> this four-week Discussion Phase is to discuss the proposal and MS> provide feedback to the proposer. MS> At the end of the Discussion Phase, the proposers, with the MS> agreement of the Anti-Abuse WG co-chairs, decide how to proceed with the proposal. MS> We encourage you to review this proposal and send your comments MS> to before 17 April 2019. MS> Kind regards, MS> Marco Schmidt MS> Policy Officer MS> RIPE NCC MS> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
