Hello Andreas, 1. A2P messaging does not come under privacy of information. Hence, it is legal for us to track each and every A2P messages.
2. Neither operator nor sender takes responsibility for spam in the court of law, and the only liable person is the channel provider, that is us. 3. We can only disconnect the client from sending further messages, and can file a suit against that person for sending spam, however, TRAI, the govt. body in our country strictly wants all vendors to enforce spam prevention mechanisms, to identify and reject spams. So spam is indeed defined by us and TRAI. 4. The sending customer puts in an ALPHA sender ID, and hence cannot be tracked as originator. Hence, all complaints finally has us as land point. 5. Network congestion occurs, and queues build up. We often need to prevent certain messages from getting delivered late hours, but send them next day. We have assembled an 8 member team to start working on the project. Regards, Sreekanth On Thu, Nov 19, 2009 at 12:31 PM, Andreas Fink <af...@list.fink.org> wrote: > there's an additional issue here. > how to define "spam". > in my case, the customer who sends the message is the originator. He is > liable for any spam complaints. However I can not filter messages away > because what I see as "spam" he might not see as spam and the receiver > neither. The receiver might have agreed to receive advertisement messages > from the sender. > > The second issue is that we are not allowed to look at the content. Privacy > laws are very strict. Telecommunications are covered under privacy. You can > not wiretap your customers phone line neither. > > The third issue is the customer pays you money to deliver the messages. So > you are obliged to deliver them. > > Normally what we see is that operators put pretty clear rules into their > contracts. If you get complaints from the receivers, you can simply hold the > sender liable. In other words, "not your problem". > > On 19.11.2009, at 06:43, Alejandro Guerrieri wrote: > > smppbox has a plugin mechanism you could hook into. That would be the most > elegant approach imho. Check the examples, there's a C plugin showing how to > do it. > > Regards, > -- > Alejandro Guerrieri > aguerri...@kannel.org > > > > On 19/11/2009, at 4:23, Sreekanth GS wrote: > > Hello Nikos, > > 1. The SMPP Connection is not used by a single client, he re-distributes it > to n levels. So the source of spam may not be from the direct client. In > countries like ours [India], there is no spam filtration from the operator, > and we are directly connected to the operator. So, above us, no spam > filtration works. > > 2. We transmit around 1-1.5 million messages a day, in a 16 hour window, > and hence we badly need the spam filtration mechanism, and it is not viable > for us to reject messages assuming spam, and we can only hold, verify and > then release to the SMSC. > > 3. Even if a message is caught as spam, and rejected, we need to > acknowledge back that it was rejected due to spam. I really dont think a > firewall would be above to send back that rejected PDU information, rather > than dropping the packets. > > Regards, > Sreekanth > > 2009/11/19 Nikos Balkanas <n...@amdtelecom.net> > >> Hi, >> >> I will have to agree with Alvaro. Data mining, fraud, illegal and spam >> messages are a can of worms that if kannel ever gets into, there is no way >> out, with all legal ramifications. Not to mention a performance killer. Plus >> a modular front end filtering would be much more flexible and customizable. >> >> For the smppbox interface I would like to stress 2 things: >> >> 1) The average spammer or drug dealer won't use an SMPP connection to send >> their messages. Upstream ESMEs will take responsibility for filtering them. >> 2) An intelligent firewall could be used, one that would block all >> offensive packages, based on content. >> >> BR, >> Nikos >> >> ----- Original Message ----- From: <sreeka...@tngicube.co.in> >> To: "Alvaro Cornejo" <cornejo.alv...@gmail.com> >> Cc: <devel@kannel.org> >> Sent: Thursday, November 19, 2009 2:41 AM >> >> Subject: Re: Interface to bearerbox >> >> >> Hello Alvaro, >>> >>> Indeed the same would suffice for kannel, but when the it comes to usage >>> with smppbox, I personally don't think it is enough for that is our >>> experience. >>> >>> Regards, >>> Sreekanth >>> Sent from BlackBerry® on Airtel >>> >>> -----Original Message----- >>> From: Alvaro Cornejo <cornejo.alv...@gmail.com> >>> Date: Wed, 18 Nov 2009 18:55:44 >>> To: Sreekanth GS<sreeka...@tngicube.co.in> >>> Cc: <devel@kannel.org> >>> Subject: Re: Interface to bearerbox >>> >>> Hi >>> >>> Kannel is a backend or a gateway for sending/receiving messages. >>> Kannel is designed to handle huge amount of SMS traffic transparently >>> to/from any external application, so you don΄t need to handle all kind >>> of protocol issues. >>> >>> All you said is usually done through an external application of your >>> own, with whom you can do all filtering/billing/features you >>> need/want/desire. >>> >>> You do not need to patch / modify kannel for do what you want. Just >>> with your own frontend will suffice. >>> >>> Regards >>> >>> Alvaro >>> >>> On Wed, Nov 18, 2009 at 6:27 PM, Sreekanth GS <sreeka...@tngicube.co.in> >>> wrote: >>> >>>> Hello All, >>>> >>>> We are presently engaged in using kannel as our SMPP Client, and for the >>>> backend of smppbox. However, the interfacing to bearerboxes has been >>>> quite >>>> inadequate for us. >>>> >>>> Hence, we plan to develop a viable interface to bearerbox that will/can: >>>> >>>> 1. Accept connections from smppbox, smsbox, sqlbox etc. >>>> 2. Log received MSG structs to a db pool. >>>> 3. Select specific messages from db pool using regex. >>>> 4. Transmit selected messages in (3) to bearerbox. >>>> >>>> Similarly, catch MO/DLR returned by bearerbox. >>>> 1. Select specific messages from db MO/DLR pool using regex. >>>> 2. Send back the same to smppbox, smsbox, sqlbox etc. >>>> >>>> Why all this? >>>> >>>> smppbox transmits messages directly to bearerbox. >>>> -> There is no hold and transmit scenario. >>>> -> Manual approval of messages is not possible (in case of spam >>>> threats). >>>> -> In between prioritizing of messages is not possible. >>>> -> Manual modification of data is impossible, only automates is possible >>>> using plugins. >>>> -> Reject messages, hold messages (in case of queues at off-times/night) >>>> for >>>> a duration is impossible >>>> -> There is no flexible control over the messages. >>>> >>>> How to proceed: >>>> 1. Accept connections from other boxes. >>>> 2. Communicate with other boxes. >>>> 3. Store and retrieve data to and from db pool. >>>> 4. Communicate with bearerbox. >>>> >>>> Hoping to see some helping hands, >>>> >>>> Regards, >>>> Sreekanth >>>> >>>> >>> >>> >>> -- >>> >>> |-----------------------------------------------------------------------------------------------------------------| >>> Envνe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier >>> celular y Nextel >>> en el Perϊ, Mιxico y en mas de 180 paises. Use aplicaciones 2 vias via >>> >>> SMS y GPRS online >>> Visitenos en www.perusms.NET www.smsglobal.com.mx y >>> www.pravcom.com >>> >>> >> > > > -- > Regards > Sreekanth G S > Chief Technology Officer > +91.9249522046 > > TNGiCUBE Technology Resources (I) PVT LTD > B-29, Krishna, > Althara Nagar > Sasthamangalam P.O. > Trivandrum 10 > > Tel +91-9961412227 > +91-9947033004 > +91-471-3056763 > > > The information contained in this email is private & confidential. It is > intended only for the use of the person(s) named. If you are not the > intended recipient, you are notified that any dissemination or copying of > this communication is prohibited and kindly requested to notify the sender > and then to delete the message. TNGiCUBE gives no representation or > guarantee with respect to the integrity of any emails or attached files and > the recipient should check the integrity of and scan this email and any > attached files for viruses prior to opening. > > > > -- Regards Sreekanth G S Chief Technology Officer +91.9249522046 TNGiCUBE Technology Resources (I) PVT LTD B-29, Krishna, Althara Nagar Sasthamangalam P.O. Trivandrum 10 Tel +91-9961412227 +91-9947033004 +91-471-3056763 The information contained in this email is private & confidential. It is intended only for the use of the person(s) named. If you are not the intended recipient, you are notified that any dissemination or copying of this communication is prohibited and kindly requested to notify the sender and then to delete the message. TNGiCUBE gives no representation or guarantee with respect to the integrity of any emails or attached files and the recipient should check the integrity of and scan this email and any attached files for viruses prior to opening.
