[anti-abuse-wg] Email Spam & Spam Abuse Definitions

On Mon, 29 Apr 2019 11:32:23 +0100
Richard Clayton <richard at highwayman.com> wrote:
<snip>
> 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