Please.... I'm allways having troubles sending subscription requests to gmail or google apps account. I send like 100 per day because is a free live chat service and users link their website to their gmail account.
I was supposed to be in a white list but now users are not receiving their subscription request and I have hundreds of complaints by mail. Could somebody explain me what do I have to do, or which is the daily limit if any? thanks so much, Sebastian On Fri, Mar 22, 2013 at 11:59 AM, Jesse Thompson < [email protected]> wrote: > On 3/21/2013 9:21 AM, Simone Marzona wrote: > >> It often happened that for some reason if one single ip was sending spam >> messages all around than an entire c-class network was blacklisted... >> This was not funny for legitimate senders. >> > > Yeah, that's a poor anti-spam implementation. I've used c-class > blacklists to greylist email, but using c-class blacklists for rejecting > email is not wise unless the anti-spam operator knows exactly what they are > doing. > > > > What if if your xmpp chat server is blacklisted for just some day even >> if your users didn't do evil (cit) ? >> > > It depends how the XMPP service operator implements anti-spam. > > For example: Google is blocking invitations, not messages. > > So, if you run a service that has a compromised account that causes you to > get blacklisted for a day, then it's not as big of a problem if remote > service blocks new invitation for that day, but still allows messages to be > sent between subscribed users. > > > > ...you can't trust users. Moreover if you're administering a xmpp >> service you DO NOT TRUST your users. >> > > You're assuming that all XMPP services don't know who their users are. > Operators running an open registration service have different security > requirements than those who provide XMPP services to known users. > > I was saying that you can't trust your "victim" users to have a client > that has anti-spam features to protect against the naughty users on remote > services. > > > Now some what if.. >> > > Oh good, brainstorming... > > > > - create some basic rate policy for specific message types (invites..) >> >> - use some Bayes rule to parse message content. Dirty job: some kind of >> pipe to spamc/spamd.. just like we did on old email servers.. (ok ok.. >> performance problem ahead, difficult to parse file transfer, video/audio >> stream, otr-featured, and so on..) >> >> - some year ago I found that some University in UK used to log every >> message exchanged (the user was informed with a banner/service announce >> at logon time) for future analisys: could this be some kind of spam >> training? >> >> Open registration of users, in my opinion, is not the problem, and it >> isn't similar to open smtp. >> The problem is how to manage the user data AFTER registration: some kind >> of auto blocking of users based on chat behaviour, messages type/rate >> sent/received.. and so on.. >> > > I don't want to say that these are bad ideas, since effective anti-spam > needs to be multi-faceted in the face of evolving attacks. > > However, Google is dealing with a situation where the spammer has to only > do this: > > 1. Generate an account on random service X > 2. Invite one remote user to chat > 3. Send one message > > repeat step 3 if possible/desired, > repeat 2-3 if possible > repeat 1-3 forever > > Assuming that there are any services that allow spammers to repeat step 1 > without restriction, then the first win for anti-spam protection is for > receiving-side service operators to blacklist those abusive services from > sending any invitations. > > We can't rely on XMPP service operators to voluntarily begin restricting > account creation, any more than SMTP operators relied on open relayers to > voluntarily disable open relaying. > > Jesse >
