[anti-abuse-wg] Question about spam to abuse inbox

I give up, I am just wasting my time trying to argue, I want to make it
clear I still disagree with you but arguing is a waste of time.

-Cynthia

On Sun, Feb 21, 2021, 05:30 Ronald F. Guilmette <rfg at tristatelogic.com>
wrote:

> In message <CAKw1M3N=mchvW1PTWzbCAj+FyifaZB=
> u1E9un9cCc8uY-F7UtA at mail.gmail.com>,
> =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me at cynthia.re> wrote:
>
> >Can you please stop attacking ideas (such as web forms) implying that they
> >only have malicious use cases.
>
> You have missed my point entirely.
>
> Web-based abuse reporting forms are not merely "an idea" any more than
> discrimination is merely an "idea".  Rather it is an attitude and a
> way of life.  It is the Internet equivalent of refusing to wear a
> face mask, for the good of all, in a crowded elevator in the middle of
> a global pandemic.  It is demonstratably and provably a selfish and
> self-serving anti-social behavior pattern.  I don't know where you
> live, but where I live we have already had more than enough of this
> kind of attitude, and this kind of childish anti-social behavior.
>
> >> 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.
>
> Again, you have missed my point quite entirely.
>
> Some providers have clauses in their service contracts that say explicitly
> that custiomers who are caught spamming will face a manditory (and heavy)
> "cleanup fee".  Many other providers do not have such clauses in their
> standard service contracts.  Can you guess which providers are the sources
> of most spams?
>
> >> 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.
>
> Fine.  Have it your way.  The point can be argued either way, but I see no
> point in us doing so at this moment, since I made a different and
> *overriding*
> point that renders this question of parsing abuse reports sent via email
> moot.
>
> I say again, any professional treatment of an abuse report will necessarily
> require a human being to actually LOOK at the bloody thing.  When viewed
> with that context, the manner in which the report arrives is utterly
> irrelevant.
>
> If a human being is, in the end, going to end up looking at the bloody
> thing
> anyway, then what difference does it make if the report arrives via email
> or via a web form?  None.  None at all.
>
> >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.
>
> I do not assume.  I observe.  And I've been doing this a LONG time.
>
> With the highly prohable exception of my friend Michele Neylon, it has
> been my experience that those providers that set up web-based abuse
> reporting forms ignore most or all of what they receive via those
> forms.  Either that or they just forward the reports on to their pet
> spammers, whichj is provably even WORSE thanm idf they had just dropped
> the reports into /dev/null.
>
> >> 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.
>
> Oh!  So you want and indeed *demand* that the spam *victim* should be
> obliged to fish this tidbit of information out of the headers, so that
> the actual offending network doesn't have to do that part of the analysis
> work, yes?
>
> Where I come from, that's called cost shifting... onto the victim...
> and it is no more morally or ethically defensible than trying to
> justify sexual abuse by saying that the victim wore a short skirt.
>
> >This report could then automatically also be sent to the customer in
> >question
>
> Do you really not understand why this is an extraordinarily BAD IDEA?
>
> >(I believe Hetzner as an example does this or something similar.)
>
> Yes, Hetzner has more than once ratted me out to their spammer customers.
>
> Are you seriously holding that company up as a shining example of ethical
> behavor for others to follow or be guided by??
>
> >> 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.
>
> So you're saying that you work as an outsourced abuse department for
> various
> providers?  And you're OK with spammers being allowed to send out 200
> spams,
> but you really don't want to then have to deal with 200 reports of same?
>
> I just want top make sure that I understand hat you're saying.
>
> Which providers do you perform this function for?  And which of them have
> outbound port 25 connects enabled by default?  Which of them have cleanup
> penalty charges in their standard service contracts?
>
> >But if I had a way to group it by sender IP address, that would be a lot
> >more manageable.
>
> Yea.  For you.  Not for the poor spam victims however.
>
> Anyway, you will be happy to know that there is a way to search a whole
> large set of emailed abuse report messages that will allow you to easily
> find all of the ones that mention a particular IP address.  It's called
> fgrep, and I'll be happy to send you more information about that, if you're
> interested.
>
> >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.
>
> I am pleased that we found something to agree on.
>
> >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.
>
> Believe me, if I receive 200 spams from *your* network in one day, I'm
> going to be WAY BEYOND annoyed.
>
> >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).
>
> The true solutions are what they have always been... Block outbound
> port 25 by default[1], opening it up only based on good cause shown, and
> have
> service contracts that contain "cleanup charge" clauses.  These things are
> known to work.
>
> If the abuse handling department of any given provider is *ever* finding
> itself inundated with incoming abuse reports, then by definition, that
> provider is doing at least one thing wrong, and more likely several
> things wrong.
>
> The problem isn't and never had been the means or medium by which spam
> victims report spam to providers.  It has always been what it i now, i.e.
> a lack of will to get serious about limiting the problem.  And this in
> turn is mostly cause by teh same lack of appreiciation of the *real*
> costs of doing the Right Thing or, alternatively, the Wrong Thing, whicjh
> also explains why some providers still stupidly refuse to implement BCP 38.
>
>
> Regards,
> rfg
>
>
> [1]  How many spams have you gotten in the past 5 years from Comcast end-
> consumer broadband lines?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20210221/9d07b72b/attachment.html>