Darren Schreiber

Hi Brian,      I think your issue is different than Maries. I agree your screen looks right. I'll file this with engineering on Monday and have them take a look.

Hi guys,       There was an update to the Monster UI. The apps screen was redone. The fact that it's even showing up on the left tells me your browser has an old version somehow. Can you try clearing your cache and reload?

Marie - would you mind filing #1, #2 and #3 as separate comments/ideas in the product ideas forum? We should track them individually and get these addressed.

#1 is a neat idea as it's convenient. I think we'll discuss that with engineering. #2 is tricky because converting from DOC, DOCX, etc. formats doesn't always render the same when TIFF, and the document must be converted when sent. If we did this, we can't guarantee it would always "look right" which will frustrate people. But we can see. #3 We've had a bunch of requests to be able to have a "company wide" fax number, and are investigating that concept. #4 Already exists #5 You'll be able to customize the domains on the next release.

Please check the other thread for known limitations.

There are a few additional surprises pending in that tool. Stay tuned. (But it should give you the basic raw data people have wanted for a while now, in easier form)

Hi there,      A few comments here: 1) The overall pricing summaries are not yet accurate (as you've noticed). Please ignore them. I will remove them today so they don't confuse you. There is actual supposed to be a "what you bill your clients" and "what we bill you" but it's proving challenging because some customers have varying price plans. 2) The summaries on the individual accounts are only for RIGHT NOW, when you run the report, but the CDRs are for the month you requested. I realize this is confusing, but the issue is we don't track the summaries month-over-month. We're working on that. We still feel it's useful to know the summaries. I've tried to loudly make that obvious on the report but might just remove it if it causes confusion. 3) The CDRs are not sorted. We're working on a solution for that. The point of releasing the tool in this state was because it has the raw CDRs, which is what most people wanted. There are a BUNCH of additional enhancements planned for this tool, so stay tuned.

We did plan to keep it open. It felt like less to manage. But after watching you guys interact, and listening to your concerns, I agree with you now. See, we do listen to you ;-)

This is almost creepy, did you just randomly post this? We just had a long long conversation about this yesterday, as Katie noted. haha.

OK, well as long as we're on the same page in regards to how we're going to progress, that's great!

I believe the Automata option (and the blinking light being the only identifier) is actually the correct behavior. It's not supposed to show anything on the screen when the call is parked - the light is simply supposed to illuminate.

Your response indicates you don't understand what back scatter is. What those services are doing is more complex than you're stating as they have (hopefully) accounted for backscatter. Please read http://en.wikipedia.org/wiki/Backscatter_%28email%29

Ironically, the current mechanism is to reject the email outright. The error you're receiving is from whomever sends your email to us - they don't even get far enough where we generate a bounce-back. In other words, we deny the SMTP connection. That, inherently, is the problem. We have no opportunity to customize the message much. We can add about 100 characters of clarifying text which may, or may not, end up in the response that YOUR email provider generates to you. But there's no guarantee you'll see anything. We're working on ideas for this.

FYI, we are aware of this and it will improve over time. The main challenge here is unauthorized emails actually might be spam attempting to generate "back scatter". This is a common spam tactic where a spammer intentionally emails a known server that will "bounce" emails, using a forged From: address. This inherently generates a reply to the spammer's target in the form of a bounce.

In the advanced provisioner you can already assign options "account-wide". Are you saying just the BLF keys can't be done account wide?

We hash the GUI passwords for Kazoo at create time, so I find this hard to believe. I will check it though.

When the provisioner tool was created, encryption wasn't available in many cases. In addition, adding it can lead to other issues (like people using the same user/pass for all their clients, or not knowing how to configure it, etc.) We added some functionality to provisioner which blocks scanning requests and does not allow you to download the config files without knowing a few things about properly crafting a request. So this is not actually as insecure as you're pointing out. It's been pretty solid. At this point, you'd basically have to craft a perfect request and know the exact MAC address of the phone you want to grab. In the future, we'll be locking this down by IP and providing functionality to deal with dynamic IPs. This should put an end to this, encryption or no encryption.