ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Levels of proposals

2015-12-11 13:35:15
On Thu, Dec 03, 2015 at 04:36:16PM -0800, Brandon Long wrote:
Submission IPs seem like the largest level of risk, and from my gross
understanding of anti-spam, pretty minor.  I'm not sure what the current
source levels are, but submission IPs would be most useful in the case of
hijacked account spam or abusive account spam.  Presumably, if spam reports
about such are forwarded to the MSP, then the MSP can easily store the
information somewhere other than the easily forged headers and take the
appropriate action.  Only if the answer is "they don't take action" would
you need more.

I'm going to try to be kind here, but I'm probably not going to succeed.

Because the sad answer, in 2015, is almost always "they don't take action".

If all email providers were behaving in a professional, ethical,
responsible fashion -- which includes, among other things, individually
answering and acting on every single message sent to their "abuse"
address -- then we could give this serious consideration.

But they're not.  They haven't been for years (or in some cases, decades).
Oh, they're very concerned with not letting spam in -- to the point
where I see FPs or reports of FPs from them on a near-daily basis --
but they're apparently far less concerned with the spam they let out.

Which means that most of us trying to defend ourselves from the spam
cannons operated by Amazon (for example) don't even bother sending abuse
reports any more.  After years without so much as an acknowledgement
(let alone a polite thank-you for our assistance and a meaningful apology
for the abuse we've suffered at their hands) what would be the point?

        [ Note that, for example, Amazon AWS doesn't even accept abuse
        reports except through a byzantine process using a horribly-designed
        web form.   And then, as far as I can tell, it discards them. ]

Instead we have come to rely on numerous techniques (such as those
Chris Lewis and others have described) that in turn rely on scraps of
information -- including submission IP addresses.  Or we just block
them outright, which is something I've done with AWS.

This is clearly suboptimal.  I really don't want to do it.  But the
refusal of so many large operations to run themselves properly has
made it necessary.

---rsk

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp