Voicemail to email mess up

Had an issue where my Public IP used to send voicemail to email was blacklisted so emails started failing. Settings dictate to delete the voicemail when emailed. Does that mean that every voicemail that was unsuccessfully emailed was deleted or are they in a queue because of the email rejection?

They should have bounced to either your root or asterisk user on the server.

The “Delete Voicemail” setting will do exactly that regardless if there is an email generated (or if the voicemail is attached). The email part of the process happens first before the deletion but if there is no email to process, it just goes to deletion.

Consider using imap on your local mail server. Forward from that.

Can you elaborate? What is there to consider?

Local buffering, ability to survive upline denials until you resolve the problem, but mostly because it works :slight_smile:

So you’re saying send all the voicemail notices to a single IMAP account and then forward out the emails from there?!

I’m pretty sure I said didn’t say that, you can actually have many accounts on a imap server. Have you ever implemented one?

Numerous. See this is why I asked you to elaborate but instead you gave another vague statement in reply. Considering that the Voicemail App supports IMAP storage, you could have very well be talking about that when you said “Consider using IMAP”. Or you could have meant something like this, create a bunch of IMAP accounts. Or who knows, you still actually haven’t elaborated.

So the suggestion is to setup another email server, create IMAP accounts and then what? Have them check those? Use those to forward the emails onward? How would you forward them onwards? How do you delete them once they are successfully delivered?

I don’t see how putting another mail server in the way will solve the issue. Unless it’s something more like an SMTP relay server so the PBX can do SMTP auth and then that server can send it out. But let’s be honest here, if the PBX got blacklisted by places it is probably due more to a poor email/SMTP setup on either the PBX or the DNS records.

Numerous people fail to setup the proper system email, reply emails or domain information in the Postfix config. Mainly because SMTP Setup is a SysAdmin Pro (paid) feature. Why? I don’t know, it seems like a basic feature to let people configure to avoid stupid things like this. In addition to not setting up the actual PBX for proper SMTP they also forget to do things like setup valid SPF records or any other form of email validation that is standard these days.

Dude, you might possibly consider the fact that you are not the only one in the world that can chew gum and walk at the same time, If you continue to tear down everything and anyone who offers alternatives to your edicts you might well lose your fan base :slight_smile: lighten up !!

You offered a solution and I’m asking how this solution would work. Notice my first reply was asking you to elaborate and what there is to consider. I wasn’t being snarky, I was being curious. Your response was to offer up a little more information but nothing solid or what would be considered “elaboration” on the subject. As I pointed out saying “Consider using IMAP” when referring to the Asterisk Voicemail App can imply using IMAP storage or not.

Furthermore, even if I really don’t agree with the solution that doesn’t mean the solution itself is bad. I just don’t agree with it and that could be for a variety reasons. But when things like this happen and the response is vague with a “it just works” and no real offering of information, even after being asked to share, makes it hard to side in favor of it because there’s nothing to validate being in favor of it.

Shame really as I am in the process of coming up with a solution for accepting incoming email messages/attachments, parsing them for real time functions plus storing them via IMAP and retrieving them later from IMAP. This solution of yours might have given me some insight. Even worse, I could have offered insight on how to improve your current solution.

When you actually have something positive to offer, I am sure we will all listen.

As of now my imap server ( you only need one for many PBX’s) work well within a constrained campus ( most PBX’s fit that bill) and have for a long time. Mail is received and forwarded appropriately to any arbitrary email address associated with any extension. By the nature of imap’s configuration, messages won’t arbitrarily disappear, which I believe was the concern of the OP.

I just use an SMTP gateway, just need one for all my systens (PBX or otherwise), that allows me to assign an SMTP auth account for each system to monitor who is sending emails through the gateway. I let the SMTP queue deal with holding and re-deliveries (which is set to a high threshold).

That way when the destination system is allowing connections again the queue will just either make its re-attempts or I can force re-delivers from the queue as needed. By the nature of a properly configured SMTP gateway, it also deals with the concerns of the OP of messages disappearing.

Honestly though, if Postfix was configured more properly this could also be solved by adjusting the Postfix config for re-tries, hold frozen/queued messages, etc. So the PBX, itself, could hold these messages for days/weeks without being lost and could be triggered for re-delivery once the issue was resolved.

So now there are three solutions that all provide the same results for the OP. Two of which require a secondary system. They all have pros and cons that would have to be considered and compared to decide which one would be the right solution for the OP (or anyone).

If you use postfix, then you should be amazed by how incredibly flexible it is, you can easily locally mirror every email to local or other storage by account but recovery of a missing email takes manual intervention. IMHO IMAP is just easier to administer in the long run, especially when “Stuff happens” , that’s why I posted in the first place :slight_smile:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.