This is where a simple captcha system would provide effective spam control. (maybe i'll see what I can do to add this...)

I've password protected the front end to my ticketing system till then.

later...

jason...

ohh i see...sorry...

yes you are right about validation, and whitelisting, that would do the trick for emails.

perhaps a simple "local domains" list would suffice under most circumstances. This would work for me quite well as I'd then just open the system to those email addresses that meet the local domain list.

later...

jason...

David has a good point, SPAM protection is certainly something that has to be looked at.

Captcha is a feature that perhaps can be included in the project (with the ability to turn it on and off). But for tickets through email there has to be something else.

But I advise people to wait for RC3 before they try to make things themselves. This release has changes in the code that affect the project widely.

understood...will wait...

Now that RC3 is out does anyone have ideas on how to address this?

As people have mentioned, the CAPTCHA won't work... the email response mechanism seems to be the best (and only?) way to filter out junk messages. It's not ideal, but it's something.

How then would this be implemented? Is there anything currently in osticket that could be used as a base to build this little validation from?

Spam protection

How about a system where the user has to click on a confirmation link?

Not only might be helpful with spam, it will also be useful for those users to are incapable of correctly typing their e-mail address and it bounces!

Captcha is a feature that perhaps can be included in the project (with the ability to turn it on and off). But for tickets through email there has to be something else.

But I advise people to wait for RC3 before they try to make things themselves. This release has changes in the code that affect the project widely.

Yes, Captcha is a must feature!

For email I guess best would be to install (spamassassin) on your server.

Is the code in RC3 now final or are there still changes to come? Meaning is it save to program on your own without having RC4 braking the code?

i think that for email, a simple "confirmation" email, such as those used by forums, would suffice.

you submit a ticket by email

user gets an email back requesting confirmation

you confirm the request by clicking on a link like mark suggests.

ultimately, being able to have a user "register" would eliminate confirmation email's on ticket requests, and instead be simply moved to the user registration phase. at this point they'd be able to open a ticket through the web or via email without having to confirm (email and/or captcha) every time.

i intend to start work on the captcha code a.s.a.p. i really would like to remove front end authentication that i currently have in place.

o.k. that was way way way easier than it needed to be! i have a captcha method done, and it would be a breeze to add to any version of osTicket. See my thread here: (http://osticket.com/forums/showthread.php?p=1337#post1337)

later...

jason...

Captcha is a terrible option and should never be used, any one going to the trouble of addin it should best spend their time on recoding the entry linking to thier open.php

its very simple, spam bots know what to look for, we all use stock templates ands file names for them to auto spam any site

I looked at my web logs where it shows the file not found and they look for phpbb2, nuke osticket the works

well if you customize the entry to your support area then you will elimiate 90 % of the spam bots

IE changing open.php to open3.php and the links to it in the source files

this leaves the other 10% where they find the link off your main site to your support area

there you can use a image link instead of a word to get ride of half the spam bots looking for properlinks

the other half will be the spammers them selfs checking sites to update thier spam links

those guys have their bots tell them which sites found nothing and then they look for them selfs to update so those guys will get in all ways depending on how often they recheck

now that will leave very little spam coming threw and to get rid of the last we simple code in rotating file names and linking to the open.php

not hard to do and Captcha GDI is a big waste of time and annoyance to your clients

disagree

While I understand your point, I disagree in many regards.

Spam protection through obscurity is poor and short sighted, simply ask anyone that has obscured their email address by putting a '-' or '.' in it in order to prevent spam and get it off the dictionary lists (you eventually end up on their lists and getting spam anyways). While it's true that simply renaming the file and adjusting the links would thwart many crawlers, it doesn't prevent a malicious attack nor does it address an adaptable spamming system. A renamed and adjusted system would require new names and new adjustments as soon as it did fall onto someones list and would make ongoing OSTicket maintenance an issue.

CAPTCHA, while not a perfect solution, is an effective solution none the less. It is widely used throughout the Internet (Simply buying tickets from Ticketmaster requires the use of CAPTCHA). ReCAPTCHA goes a step further and eases the use of the CAPTCHA for english speaking/reading people by using actual words rather than random text.

So for me, while I would prefer to have a system where the users actually register as a user, and thus spam is reduced by only allowing registered users to open tickets, that is not a part of OSTicket today. CAPTCHA provides a minimally intrusive alternative that is commonly found throughout the Internet today. And the ReCAPTCHA solution that we integrated in this thread has a very small footprint within OSTicket making ongoing maintenance and upgrades far easier to implement.

jason...

CGI uses may deter pissed off clients but thats not the issue, we'll all see that once mabey a year if we are lucky but i tend to bend over backwards for my clients and any inconvience I see I remove

now daily spam bots are the issue, so using the GDI is not a solution

my web server filters out 10,000s of spam emails because its set up properly and i dont even use a single phrase filter so i never feard about posting my emails any where

my forums are also protected from the same features i mention and it wont allow those mad users to spam the hell out of the forums as it delays thier posting

scan any of the php based forums and you'll see thier CAPTCHA dont work either once they know where your CAPTCHA redirects you and then they inject the data

custom templates simply stop them as they love the fact that all these servers use the same file templates

I just dont see the point of using a feature that can be bypassed

and I know more then most, some of my domains are over 10 years and are on every ones spam list

let them spam, me and my clients dont see any of it

So for me, while I would prefer to have a system where the users actually register as a user, and thus spam is reduced by only allowing registered users to open tickets, that is not a part of OSTicket today. CAPTCHA provides a minimally intrusive alternative that is commonly found throughout the Internet today. And the ReCAPTCHA solution that we integrated in this thread has a very small footprint within OSTicket making ongoing maintenance and upgrades far easier to implement.

jason...

OMG i missed that part

60% of forum spam now adays have registed spam bot programs with valid emails

there is no way in hell im sitting and banning domains or IPs every day

sorry but you're logic is faulty and leads to un needed work

kill it at the source, and thats how the bots work

we can go fully flash with intergraded databases that would get rid of all the bots

but i may think differently then you as I do coding for anti cheating in games so i know how to not waste time on things as I have too many clients to worry about, and in my field hacks and bots are all ways throw our way

so no GDI is no fix

Yes, we will wait and see.

For a couple of different reasons I absolutely need an email address validation/confirmation system as described on the first post.

I'm going to begin coding it today, and hope to finish it soon. If anyone already coded something similar and would like to share it please let us know, replying to this post.

I will upload the "email val/conf" patch for v1.6 RC4 as soon as I finish it.

For those interested on my primary reasons, here they are:

1) I'm running a MMORPG/MMORST. The age / computer experience of my visitors is not high at all.

This means that a lot of users will not watch the "spam" inbox for the ticket code or they simply don't have the patience to wait for the message at all, therefore they keep recreating the same ticket with different addresses, or even with the same one.

2) My Email servers are under the supervision of a "greylisting" system. It's a simple let-any-email-pass-only-the-second-time system which cut off the 89.9% of the spam I receive.

Now, there is another antispam system used by a few hosts, which is in contrast with mine: the is-sender-email-routable system.

When the ticket code is sent to one of those serves, they try my "mail from" address for SMTP availability, and my server answer is "try again later", as the greylisting system requires. Now, really bad configured mail servers (as hotmail.it, for the record) take that as a "NO, this address doesn't exists", therefore blocking my Email.

For the reasons explained on point 1), that ticket will be recreated until a good mail server is targeted, maybe hours or days later.

Now, validating the email address won't solve neither one or the other problem, but it will definitely avoid tons of duplicated tickets to manage from my staff, since the ticket will be visible only when the email is read by the user (I plan to create a new separated group of tickets like "open" and "closed", named "not validated", which get erased after some time).

I'm sure I'm not the only one with one or both of these problems... and that's why I'd like to see my code (or a better one, of course) in the next release of osTicket. Wouldn't it be nice? :)

Any joy with your code

@[deleted]

Have you had any joy with your code? Could you post up any work you have done on this?

Thanks

Vas

Unfortunately I haven't had the time to do what I wanted.

For the point 1) I modified the ticket-sent page with a bold line pointing out that the message may be in the spam folder, that only by reading that message the ticket replies can be read and that there is no need to create other tickets or refresh the page (which creates duplicates). Most regular users have learned.

The point 2) solved itself: greylisting is widely used now and most mail servers don't use the is-sender-email-routable system anymore.

I still would like to have that modification for the occasional duplicates, but I can't afford to do it myself.

Fair enough

Thanks for posting back anyway.

Vas