Aside from the inline response, I guess I could approach several of the ISPs who bulked some of our messages and try to affirm if it's UGC spam or not. if anyone got any contacts at laposte.net or orange.fr (offlist please), IIRC they bulked us a bit on invites.
On Mon, Jan 19, 2015 at 10:22 PM, Jay Hennigan <mailop-l...@keycodes.com> wrote: > On 1/19/15 5:18, Gil Bahat wrote: > > > > I am the postmaster for magisto, an app centered around user generated > > content (UGC). we enjoy some popularity, and with popularity comes > > abuse. There are users who utilize magisto to generate content to be > > used for spamvertisement and/or other unsavory content. they will then > > "invite" users to see this content, in an unsolicited fashion, using the > > built-in content invite mechanism. > > Perhaps some form of rate-limiting on the invite mechanism would help. if we had no rate limiting, it would be spam hell (or haven, depending on your viewpoint). but if we set it too low, we start hurting our business, especially with content going viral. my goal is to see that even continuous drip-spam that maxes the rate gets dealt with swiftly. I want this stuff off my network and to make myself as least lucrative to spammers as possible. > > even if they incorporate it outside the invite mechanism, magisto still > > serves as a "hosting server" for their content. > > > > Ideally, internal user reporting would be sufficient to combat it, but > > in reality it isn't: both because users submit many false reports and > > because such a system doesn't scale. > > How do you handle user reporting? Is there an option on the content page > to flag it as having been spamvertized? Regarding false reports, a > percentage to trigger review or more aggressively rating flagged content > that has been recently uploaded might help. There is an option to flag content for review, currently no canned reason selection though, just a free text reason field. people report a lot of random stuff for no obvious reasons and no text entered. the problem becomes operator overload. being a tad paranoid, I consider the option it's not coincidental and someone is testing us. > > > DMARC can't help with regards - the messages are either entirely 'valid' > > invite messages, or otherwise do not involve our domain. > > FBL data can help, to an extent - but is again not relevant for the > > second use case or for users spamming a provider which has no > > FBL offered, or gmail who provide aggregate data only. > > Spamtrap data is generally out of reach for us - so I can't estimate its > > suitability to hunt these down. I suspect it will help somewhat, but not > > by much. > > It might be useful for the internal invite case, especially if you > incorporate a delay of sending bulk invites until checked against > spamtraps. that's a very good idea. but I have found verification services costly and only so reliable. real spamtrap data is even more expensive, assuming we will qualify. > > Services such as spamcop will not provide data to us, for the concern > > that we may listwash since we are not netblock owners. but again this > > will only give partial coverage. > > Perhaps work with your upstream to have such reports forwarded to you? > We run on amazon EC2, not a welcome host at spamcop. I inquired what would happen if we signed up for cloudflare, and they aren't welcome on spamcop either. maybe incapsula could work (same as cloudflare from the hosting perspective, they hide the real origin for security purposes), but there are some stipulations about the information not being passed to us as is or something for fears of listwashing. Couldn't quite get a hold on what they would and wouldn't be able to share with us. > -- > Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > _______________________________________________ > mailop mailing list > mailop@mailop.org > http://chilli.nosignal.org/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
