Re: [anti-abuse-wg] Email Spam & Spam Abuse Definitions
On Mon, Apr 29, 2019, 2:05 PM Richard Clayton wrote: > Systems that fail to ensure that such emails cannot be automatically > generated (by adding CAPTCHAs for example) need to be updated. > This is not possible. CAPTCHA is not a silver bullet. What it can do for sure is preventing simple automated actions on the orders of millions, maybe, but orders of hundreds of thousands are still achievable for a skilled criminal. I know some are lucky to have it working for now, but there's no guarantee. Therefore cannot be a requirement. -- Töma >
Re: [anti-abuse-wg] Email Spam & Spam Abuse Definitions
On Mon, 29 Apr 2019 11:32:23 +0100 Richard Clayton wrote: > As a result of this the working definition of spam for 90% of all > mailboxes is "email that is not wanted in the inbox just at the > moment" > This definition is not directly based on "permission" or "bulk" or any > statutory definition -- though emails that are sent with permission or > that are not sent in bulk are less likely in practice to be classified > as spam. agreed, but bulk is still relevant, maybe just not as relevant as before > >My point is that even "verify your email address" could be Spam > >Abuse. > Yes I agree (and if enough of the people who receive such messages > agree as well then such email will end up in the spam folder or will > be rejected). > Now of course the skilled humans may seek to override what the machine > learning system decides (typically for example, emails from airlines > containing boarding passes are deemed never to be spam) but this > overriding depends entirely on the senders cooperating (an airline > that sends marketing email from the same machines and with the same > crypto identifiers as their boarding passes is going to rapidly find > that their "deliverability" quickly declines. Also the problem comes in when abuse is created in order to interfere with machine learning and/or when abuse exploits the process. > >Recently I received around 14 "verify your email address" emails in > >the same 15 minutes... > There are systems, used by criminals, who will deliver hundreds or > even thousands of these within a short time period. They are used to > flood mailboxes so as to hide account takeover and other wickedness. > A short time spent with a search engine will find these :( > >I would say that sending so many "verify" emails, in such a short > >time, is Spam Abuse > I would say that it was a pretty small attack ... but I could not say > why it happened to you. If it happened to me I would look very > carefully at the rest of my email that day. > >Is anyone willing to venture a number and time period for what would > >be considered 'fair' in terms of sending verification emails? > Systems that fail to ensure that such emails cannot be automatically > generated (by adding CAPTCHAs for example) need to be updated. This > will benefit the system owner by ensuring that all signups are > genuine. yes, this is very accurate and imho should be best practise :) > You might also usefully read ... > https://www.m3aawg.org/rel-WebFormHeader > ... though in practice take-up of the proposed header has been limited > and if you are going to update your systems to generate it you might > as well update the relevant web pages to add CAPTCHAs, randomise field > names or whatever else you think will prevent automated list bombing. > Yes, but the process can be defined without specifying captcha's or randomised field names, as the abusers also have AI and also have machine learning tech, so instead of so much focus on the actual tech I am of the opinion that the process must be more clearly defined as anyone can use any tech they like. imho, WebFormHeader does/could help with counts on contact form spam and comment spam from ops perspective but already the same abuse in drip bypasses the value of the head data. your doc https://www.ripe.net/publications/docs/ripe-409 is still very valid today... Currently I have started editing the doc, but, as a lot of what you said 12 years ago, still applies today, there are still ube providers, db sales, web tools, etc and although old and mostly toothless, for independents (the 10% in your above) these kites still fly. Would it be okay if I email you what I have early next week? Kind Regards Andre
Re: [anti-abuse-wg] Email Spam & Spam Abuse Definitions
In message , ac writes
>
>Okay, so I am assuming then that my definitions of spam are accurate.
They are out of date ... on the big platforms (where perhaps 90% of the
world's mailboxes are now to be found) spam detection is entirely an
automated process ("machine learning" systems, with some guidance from
skilled humans as to what they should definitely reject)
These machine learning systems do the learning part by observing how the
users (the people whose mailboxes the systems are protecting) deal with
their incoming email. If the email is rapidly deleted or "marked as
spam" then the systems learn that the email was in fact spam. If the
email is automatically placed into a "spam folder" but the user
interacts with it and marks it "not spam" or moves it into their inbox
so that they can reply then the system learns that it has made an error
and that more email of a similar type should not be treated as spam
As a result of this the working definition of spam for 90% of all
mailboxes is "email that is not wanted in the inbox just at the moment"
This definition is not directly based on "permission" or "bulk" or any
statutory definition -- though emails that are sent with permission or
that are not sent in bulk are less likely in practice to be classified
as spam.
>My point is that even "verify your email address" could be Spam Abuse.
Yes I agree (and if enough of the people who receive such messages agree
as well then such email will end up in the spam folder or will be
rejected).
Now of course the skilled humans may seek to override what the machine
learning system decides (typically for example, emails from airlines
containing boarding passes are deemed never to be spam) but this
overriding depends entirely on the senders cooperating (an airline that
sends marketing email from the same machines and with the same crypto
identifiers as their boarding passes is going to rapidly find that their
"deliverability" quickly declines.
>Recently I received around 14 "verify your email address" emails in the
>same 15 minutes...
There are systems, used by criminals, who will deliver hundreds or even
thousands of these within a short time period. They are used to flood
mailboxes so as to hide account takeover and other wickedness.
A short time spent with a search engine will find these :(
>I would say that sending so many "verify" emails, in such a short time,
>is Spam Abuse
I would say that it was a pretty small attack ... but I could not say
why it happened to you. If it happened to me I would look very carefully
at the rest of my email that day.
>Is anyone willing to venture a number and time period for what would be
>considered 'fair' in terms of sending verification emails?
Systems that fail to ensure that such emails cannot be automatically
generated (by adding CAPTCHAs for example) need to be updated. This will
benefit the system owner by ensuring that all signups are genuine.
You might also usefully read ...
https://www.m3aawg.org/rel-WebFormHeader
... though in practice take-up of the proposed header has been limited
and if you are going to update your systems to generate it you might as
well update the relevant web pages to add CAPTCHAs, randomise field
names or whatever else you think will prevent automated list bombing.
--
richard Richard Clayton
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
signature.asc
Description: PGP signature
