Hostbill ticket system does not respect case insensitivity in emails

[tallship]

Ticket imports failing in your hostbill installation at an alarming rate, and you may not even know it.


This bug was originally reported in HostBill version 3.2.4 and still exists in HostBill version 4.9.0



If you have a department: Service@Domain.com and someone sends an email to service@domain.com, their email is rejected and shown in the ticket import log as "Not found" (None of receive emails matches any of your support department)


If you have a customer, joe@joe.com and he sends emails from Joe@Joe.com, the customers email is rejected and shown in the ticket import log as "Unregistered" (Department does not allow unregistered clients).


This behavior is contrary to the RFCs pertaining to the SMTP protocol, which (to paraphrase) states that email addresses are case insensitive - any combination of upper/lower case characters are acceptable and treated the same.


Many lost sales are occuring for hostbill owners because of this,



Many customers are having their support tickets bounce because of this


It is costing hostbill owners a lot of sales and causing them to lose customers for lack of support.


I have created a BUG report and would appreciate it if everyone could take a couple of moments to vote this most critical but up - it is costing everyone dearly, and the sooner it is fixed (it is a long standing bug for over two years now) the better.


Here is the URL:


https://help.hostbillapp.com/index.php?/bugtracker/bug/&id=468


Thank you in advance for helping to raise the priority of this critical bug. This really needs to be fixed asap.

[Enterprisevpssolutions]

Voted up.

[Enterprisevpssolutions]

Just doesn't make since why it would be cases sensitivity.

[davemarks]

Also suffering from this. Should be fixed.

[tallship]

Also suffering from this. Should be fixed.

Yes it should Dave, but if you could go to https://help.hostbillapp.com/index.php?/bugtracker/bug/&id=468 and actually vote it up that would help a lot towards getting this done.

Merely posting support for the bugfix here in the forums won't do anything towards getting kbkp to actually fix the bug - it needs to be bumped up in his bugtracker on his site to even get his attention.

Thanks

[maxim]

Voted! Thank you for information

[tallship]

Voted! Thank you for information

Thanks to everyone for voting this issue up. It is now listed in the changelog as having been resolved, although I tend to lag a bit when it comes to updates in case any major breakages are introduced.

I'll check out and test maybe later tonight if I update and report back with my findings.

Once again, thanks everyone! This was a major source of lost income and also frustration for registered users responding to tickets.

[Enterprisevpssolutions]

Do not upgrade yet it ended up breaking my email imports stating the department is not found. I even tried to add them back in with the same result.

[tallship]

Do not upgrade yet it ended up breaking my email imports stating the department is not found. I even tried to add them back in with the same result.

Thanks for that. I'll hold off. I'm currently at 4.9.0

[trasek]

The bug in bugtracker disappeared?

[tallship]

The bug in bugtracker disappeared?

kbkp marked it as fixed in 4.9.4's changelog. I guess the bugs disappear when he marks them as fixed. Since I opened the ticket, I can see it in my bugtrack under 'my bugs' or whatever it's called, and it's grayed out, presumably meaning that the bug has been fixed/cancelled/ignored/disregarded, or fake fixed.

That was the case with the estimates, which weren't fixed, but the bug was cancelled, so I can still see it grayed out in my login, but it's no longer viewable in the tracker - a convenient way of erasing history.

This is why it's not a bugtracker at all - there's no history, there's no way for people to add comments or additional information about the bug, it isn't tracked, and it shows no history of every having existing in the first place.

I haven't actually done the upgrade from 4.9.0 to 4.9.2 to 4.9.4 yet, so I have no real way of knowing if it is fixed, although it has been reported in this thread that emails are working again - there's a difference. tickets may once again be importing, but it remains to be seen whether the ticket system actually is respecting case insensitivity of email addresses as per the SMTP protocol standard.

Are you still having problems with ticket imports coming from eMaILs@cUsToMeRcOmPaNy.CoM resulting in "Unregistered" or ticket imports going to cUsToMeRsErVice@YoUrCoMpAnY.cOm  resulting in "Not Found"? in your ticket import log?

[trasek]

When i write e-mail: DoMiNiK [ at ] O2.pL from that e-mail (my second private e-mail) (it's had some digs more after dominik).
All work . It's go to departamend what i select and assing to good client with this e-mail. I work on 4.9.4

[tallship]

Okay I can confirm it's now *finally* working for me too.

There's a patch for 4.9.0, then I u/g'd to 4.9.2, then I u/g'd to 4.9.4, and then there's a patch for 4.9.4 to finally fix everything.

I've included the patch (hostbill_patch4.9.4_4485.zip) as an attachment in case anyone is having the same kinds of problems I experience where the autoupgrade module claims I need to update with previous patches and plugins (usually takes about 24hrs for my HostBill to realize that those things are actually there). If that's the case for you, and you've upgraded to to version 4.9.4, apply this patch and your ticket imports won't have empty "To" fields (like you see in the screenie below).