(1) is irrelevant because random spam will not fit the format of
these automated reports;
Only true for _some_ formats...
True. I was implicitly assuming that email-carried reports would
deliberately use a specific format designed for the purpose; if it is
non-idiotically designed, the chance of an accidental false positive
will be so low as to be ignorable.
if spamming fake reports becomes attractive enough for it to be a
problem,
That's not the point, really: even without _any_ email intending to
fool the report parser, the <abuse@> account would have to parse an
arbitrarily large amount of junk looking for things which _intend_ to
be a report.
Yes, but almost all of the non-reports will fail the first, cheapest,
check - if the format is well-designed for the purpose, the cost of
that first check will be down in the noise compared to the cost of
handling the mail at all.
I don't know what Earthlink's daily load of <abuse> email is, but I
wouldn't be surprised if it exceeded 1,000,000.
So? I'm with rsk on this one. Either they need to get more active
against abuse, or they have such a huge user base that supporting that
kind of abuse@ load is just a part of being that big. (At 1e6 a day,
given typical abuse-to-report ratios, I'd say the latter would require
something approaching a majority of the planet's population as a user
base.)
whatever other mechanism carries them will have exactly the same
problem.
Not "exactly", unless the design is foolish. It could, for example,
include a registration mechanism allowing packet filtering to
regulate the load...
And? The same list of registered sending IPs (or whatever) can be
applied to email, as that very cheap first check I mentioned above.
(If the reports are crypto-signed to deal with report forgery, this
can be done over email just as much as it can over some other
channel.)
[...] crypto-signing to validate email is a heavier load even than
crypto-signing of most other protocols.
Only if you're stupid enough to compute a signature for a substantial
fraction of the unsigned mail. You shouldn't even be considering doing
any serious crypto until the message has passed all the cheap tests.
(Furthermore, in the presence of prearrangement, crypto signing can be
made quite cheap, by choosing different crypto.)
[T]here's no reason emailed automated reports can't be shipped off
to whatever processing the putative other transport performs, rather
than going into the main abuse@ queue.
If we were only ever implementing _one_ pairing of ISPs, this is true
enough. But for this to be useful to Earthlink, they must be able to
receive reports from more than one ISP.
That's what standardized formats are good for. Mail can be sidetracked
when a known format is recognized even when others use the same format.
OTOH, for this to be useful to World, they need to be able to report
to more than one origin ISP. Does Earthlink define the format, or
does World?
Doesn't matter, as long as everyone involved agrees on it. I suspect
the first implementation out the gate will more or less set the
standard, if the idea proves to be worth doing at all.
The N * M problem is much the same with or without email being the
transport, true; but there are rather too many ISPs that decline all
<abort(_at_)domain> email.
I see no reason to care about them (well, assuming s/abort/abuse/). If
they can't be arsed to handle abuse reports at the closest thing to a
standardized abuse-reporting address there is, I see no reason why
they'd suddenly get an attack of caring just because _these_ abuse
reports come in over a non-email transport.
But there's another issue entirely that makes <abuse(_at_)domain> the
wrong tool -- the Dictionary Attack comes from IP addresses, not
domains.
That doesn't make abuse@ a wrong path; it just makes selection of the
domain you put after "abuse@" less than totally trivial. But you have
_that_ problem with an idiosyncratic transport too.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse(_at_)rodents-montreal(_dot_)org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg