This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] Question about spam to abuse inbox
- Previous message (by thread): [anti-abuse-wg] Question about spam to abuse inbox
- Next message (by thread): [anti-abuse-wg] Question about spam to abuse inbox
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Q
q at as207960.net
Sun Feb 21 09:21:24 CET 2021
Hello all, > I believe Hetzner as an example does this or something similar. They indeed do. I've noticed it especially with reports from the German Federal Office for Information Security when I've left portmapper open to the internet or something else equally harmless in its intent. Much better dealt with by the customer directly, as Hetzner could do almost nothing in this case. Thanks, Q Director [image: https://as207960.net] <https://as207960.net> <https://www.youracclaim.com/badges/4570b2d1-947f-426a-832d-d0e4bf445267/public_url> https://as207960.net AS207960 Cyfyngedig Phone: +44 29 2010 2455 (ext 601) Fax: +44 29 2010 2455 Address: 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU AS207960 Cyfyngedig, trading as Glauca Digital, is: - a limited company registered in Wales (№ 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>) - a registered data controller with the Information Commissioner's Office (№ ZA782876 <https://as207960.net/assets/docs/ico_registration.pdf>) - registered for VAT in the EU (№ EU372013983) On Sun, 21 Feb 2021 at 02:44, Cynthia Revström via anti-abuse-wg < anti-abuse-wg at ripe.net> wrote: > Ronald, > > Can you please stop attacking ideas (such as web forms) implying that they > only have malicious use cases. > > > I hold them responsible because they obviously > > fail to have in place contractual clauses that would persuasively > > deter this behavior on the part of their customers. > > In many cases it is practically impossible to know if your customers are > sending legit emails or spam without having people reporting it. > As TLS is used in many cases now, the provider can't look at the network > data to see what the customer is sending even on a technical level, > disregarding any trust/potential legal issues. > > > The provider in question is a perfectly lousy coder and is thus > > unable and/or unwilling to write code to parse emailed abuse > > reports. > > Hi, I am actually primarily a software dev and not a network engineer, it > is not even close to as easy as you make it out to be. > Sure you can have a regex to extract IP addresses and other messy things > like that, but you can't be sure what that address is, it might be your > customer, it might be the address they say you attacked, etc. > My point here is that parsing free form text in this way without having a > clearly defined structure is far from trivial. > Also please stop assuming bad faith by saying that providers are > "unwilling" to do this. > If they could drastically lower the amount of manual work needed here with > a bit of code, they absolutely would in almost all cases. > > > And anyway, don't actual human beings need to look at these things, > > in the end, in order to be able to react to each of them properly > > and in a professional fashion? > > Web forms can have pros and cons, I am just going to take the case of a > VPS/Dedicated server hosting company. > > If the hosting company provides a web form, they can have a field where > they explicitly ask for the offending IP address. > This report could then automatically also be sent to the customer in > question, because we shouldn't assume the customer is malicious, they might > just have a bad config that made them a relay for example. > This could make it so the report is acted upon sooner potentially as the > hosting company might take a few days to reply but maybe the customer can > act sooner. > (I believe Hetzner as an example does this or something similar.) > > > > A provider that is routinely receiving so many abuse reports that > > it can barely keep up with them all has bigger problems that just > > the manner in which abuse reports are received. > > Due to the automated procedure by some providers for abuse reports, if I > have one bad host sending spam, I might get an abuse report for every > single email they receive, so even if it is just one customer I might wake > up to 200 emails. > But if I had a way to group it by sender IP address, that would be a lot > more manageable. > (this was just a hypothetical example) > > Now I absolutely agree that having an abuse email address that is acted > upon in a reasonable amount of time (maybe a week or so) is still essential > as the web forms aren't standardised or might rely on technology like > captchas. > But if you send me 200 emails about the same host in one day, I am > probably still going to be mildly annoyed and I could see how this is > actually unmanageable for larger providers. > > I think the true solution here is just to have a standard email template > or similar so providers could easily and reliably parse it automatically > (at least partially). > just a very quick example that I didn't consider for more than a minute: > the standard could be as easy as just beginning every report email with > "abuse-host=192.0.2.20,192.0.2.21\n\n" and whatever other fields are needed. > > -Cynthia > > > On Sun, Feb 21, 2021 at 2:51 AM Ronald F. Guilmette <rfg at tristatelogic.com> > wrote: > >> In message <20210218200036.066496E3600F at ary.qy>, >> "John Levine" <johnl at taugh.com> wrote: >> >> >Report web forms are out of the question because they do not scale. I >> >send about a hundred abuse reports a day about spam received from all >> >over the Internet, and I have no interest in using your form or anyone >> >else's to make a manual special case for under 1% of my reports. >> >> I'm real glad that John posted the above comment, as he has saved me >> from having to do so myself. (But I will take this opportunity to >> elaborate on what John said anyway.) >> >> I am in 1000% agreement with John on this. Abuse reporting forms do >> not scale... at least not for the *victims* of the abuse. >> >> I report email spams... by far the most common form of network abuse... >> to dozens of different providers every week. At the moment in time >> when I send each of these reports, I have already been abused by each >> of these providers. (I hold them responsible because they obviously >> fail to have in place contractual clauses that would persuasively >> deter this behavior on the part of their customers.) >> >> To make me "jump through the hoops" of first even just *finding* each >> provider's unique abuse reporting web form, and then navigating it >> sufficiently well to insure that I have dotted all of the i's and >> crossed all of the t's, as required, uniquely, for each different >> provider, just *adds* injury to the insult that I have already suffered >> at the hands of these same providers, and these same networks. >> >> The demand to use a web-based reporting form is itself a form of cost >> shifting. It shifts more of the costs of dealing with network abuse >> onto the victims of abuse and away from the providfers that are actually >> originating the abuse in the first place. In that sense it is arguably >> the same as spam itself. Email spam only exists because it is a way >> of shifting the costs of advertising onto the recipient and away from >> the senders. Likewise, demanding that I must find my way to, and then >> properly complete *your* unique web reporting form is yet another way >> of shifting the costs of dealing with *your* abuse of *my* inbox away >> from yourself and onto me. Sure, it is maximally convenient FOR YOU, >> but how about a little more consideration for the victim? >> >> As John and others have noted, if I take up *my* time and effort to >> report to you abuse that is coming from *your* network, then I am NOT >> doing that for *my* benefit. Rather all of the benefits of abuse >> reports flow to the network operator of the network where the abuse >> originated. >> >> I am not an imbecile, and I can easily enough block any arbitrary sender >> in my own local configuration, either by full email address, or by >> domain name, or by IP address range. Thus, nothing obligates me to >> report any spam, and I can easily enough prevent myself from gettting >> spammed twice or more from the same source. So how does it benefit >> *me* as a spam recipient, or send in a spam report? >> >> The answer is that it doesn't. Period, full stop. I only do it out of >> a sense of community responsibility, i.e. to do my part to help pick >> up trash that other people leave lying around on the Internet. In an >> ideal world the networks/providers who are the recipients of my spam >> reports would be greatful for my help in truing to keep their networks >> clean, EVEN TO THE POINT WHERE THEY SHOULD PAY ME OUT OF GRATITUDE upon >> receiving any professionally prepared report from me. But they don't. >> (Sigh.) At the very least they should have the minimal courtesy and >> respect to not make the task of sending them a report more cumbersome >> and more tedious than it needs to be. Web reporting forms do the >> exact opposite, and they are thus every bit as anti-social as spam >> itself. >> >> >> Regards, >> rfg >> >> >> P.S. Some providers try to justify or excuse their clearly anti-social >> demand that everyone reporting abuse to them must use a web form by >> claiming that they get too abuse many reports, on a regular basis, to >> allow them to do anything sane or useful with such reports UNLESS they >> come to them via a web form. >> >> This is 1000% bullshit, and it indicates two things: >> >> 1) The provider in question is a perfectly lousy coder and is thus >> unable and/or unwilling to write code to parse emailed abuse >> reports. >> >> And anyway, don't actual human beings need to look at these things, >> in the end, in order to be able to react to each of them properly >> and in a professional fashion? If so, then how does the additional >> automation of a web form even provide any real or useful service to >> *either* the originator of an abuse report *or* to the sender of >> such a report? It doesn't, clearly. It is just a way of maximally >> inconveniencing the originators of abuse reports, and thus to >> quite apparently deter them from reporting AT ALL. >> >> In fact, for me, any time a provider says to me "Oh, you need to >> use our web form to report that" I take any such statement as a >> nearly 100% reliable indicator that the provider/network in >> question is going to be routing whatever I submit directly to >> /dev/null. Any provider that is making *any* attempt to >> "automate" abuse handling is, by definition, trying to *avoid* >> having any human ever look at abuse reports. And it logically >> follows that any provider that is trying its best to AVOID looking >> at abuse reports will NEVER have a human look at any such, which >> in turn clearly implies that no abuse report will ever be actioned >> by that provider in any way. (Example: Digital Ocean. But I can >> easily cite many many more.) >> >> 2) More importantly, it speaks volumes about the provider in question >> when and if he/she/it claims that they are receiving "too many >> reports" on a regular basis to allow them to be handled via email, >> rather than via a web form. >> >> To any and all such providers, I have a stock reply: Oh really? >> >> A provider that is routinely receiving so many abuse reports that >> it can barely keep up with them all has bigger problems that just >> the manner in which abuse reports are received. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20210221/91e8efba/attachment.html>
- Previous message (by thread): [anti-abuse-wg] Question about spam to abuse inbox
- Next message (by thread): [anti-abuse-wg] Question about spam to abuse inbox
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]