[anti-abuse-wg] Preventing spoofed amplification DDoS attack and email spam
Hello Everyone, I'm being intentionally moderated by the co-chair Brian without my replies being approved for almost a week, all of it in order to intentionally censor me for the near elections. My following technical solution will completely prevent any kind spoofed ip packets and any kind of spoofed amplification DDoS attacks: https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html Spoofed ip traffic is a source for internet abuse, as well as spoofed amplification DDoS attacks. If I'll have the honor of being elected I'll work to have it implemented at a global scale, as well as my following technical solution to prevent email spam: https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html A world without email spam will be a much more effective world, the time it will save is enormous. I hope to receive the support of RIPE Anti-Abuse Working Group for the above that will have a major impact on defeating abuse in the Internet, instead of a block from Brian. Respectfully, Elad
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Is this "Alessandro Vesely" person from an alternate universe or something? "The Police aren't going to respond to a call about someone breaking in to my house... so let's just remove the phone number from the phone book all together." What. The.. F On Mon, May 4, 2020 at 8:29 PM Alessandro Vesely wrote: > Hi, > > On 29/04/2020 13:22, Gert Doering wrote: > > > > If people *want* to handle abuse reports, they do so today already > > (and if they mess up their mail reception, the NCC will check this today > > already, and let them know). > > > > If people *do not want* to handle abuse reports, this proposal will not > > make them. > > > The above is unquestionable truth. There is a grey area, where a mailbox > doesn't work because of misconfiguration, mailbox full, or similar issues. > Validation might help in those cases. > > However, statements like: > > The “abuse-c:” will be mandatory for all aut-nums > > are in conflict with the unquestionable truth quoted above. Please, allow > abuse-c to be empty! I have to keep a dont-send list of non-responding > abuse > addresses. Some 70% of the complaints I would have sent hit that list. It > would be more practical to have an empty abuse-c entry in the first place. > > In addition, having networks without abuse addresses makes them more easily > identifiable. RIPE NCC could compile the relevant IP addresses into an > easily > usable format, for example one readable by rbldns. Rather than > following-up > and threatening resource revocation, upon repeated validation failures, the > RIPE NCC should just remove the non-working abuse-c entry, thereby adding > the > relevant IP addresses to the "no-complaints" list. > > A web form to report bouncing abuse addresses would be useful too. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
As long as the ASNs that are not maintaining an abuse address are published along with the no complaints list, I personally have no complaints. From: anti-abuse-wg Date: Monday, 4 May 2020 at 3:59 PM To: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox") Hi, On 29/04/2020 13:22, Gert Doering wrote: > > If people *want* to handle abuse reports, they do so today already > (and if they mess up their mail reception, the NCC will check this today > already, and let them know). > > If people *do not want* to handle abuse reports, this proposal will not > make them. The above is unquestionable truth. There is a grey area, where a mailbox doesn't work because of misconfiguration, mailbox full, or similar issues. Validation might help in those cases. However, statements like: The “abuse-c:” will be mandatory for all aut-nums are in conflict with the unquestionable truth quoted above. Please, allow abuse-c to be empty! I have to keep a dont-send list of non-responding abuse addresses. Some 70% of the complaints I would have sent hit that list. It would be more practical to have an empty abuse-c entry in the first place. In addition, having networks without abuse addresses makes them more easily identifiable. RIPE NCC could compile the relevant IP addresses into an easily usable format, for example one readable by rbldns. Rather than following-up and threatening resource revocation, upon repeated validation failures, the RIPE NCC should just remove the non-working abuse-c entry, thereby adding the relevant IP addresses to the "no-complaints" list. A web form to report bouncing abuse addresses would be useful too. Best Ale --
Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Hi, On 29/04/2020 13:22, Gert Doering wrote: > > If people *want* to handle abuse reports, they do so today already > (and if they mess up their mail reception, the NCC will check this today > already, and let them know). > > If people *do not want* to handle abuse reports, this proposal will not > make them. The above is unquestionable truth. There is a grey area, where a mailbox doesn't work because of misconfiguration, mailbox full, or similar issues. Validation might help in those cases. However, statements like: The “abuse-c:” will be mandatory for all aut-nums are in conflict with the unquestionable truth quoted above. Please, allow abuse-c to be empty! I have to keep a dont-send list of non-responding abuse addresses. Some 70% of the complaints I would have sent hit that list. It would be more practical to have an empty abuse-c entry in the first place. In addition, having networks without abuse addresses makes them more easily identifiable. RIPE NCC could compile the relevant IP addresses into an easily usable format, for example one readable by rbldns. Rather than following-up and threatening resource revocation, upon repeated validation failures, the RIPE NCC should just remove the non-working abuse-c entry, thereby adding the relevant IP addresses to the "no-complaints" list. A web form to report bouncing abuse addresses would be useful too. Best Ale -- signature.asc Description: OpenPGP digital signature
