Nagios MMS not being received by ATT Iphones

[isadmin]

I am receiving my mms messages through ATT and one thing you can try is removing nagios from the send from
tag of the email....we use [email protected] and send to mms.att.net
to get our messages..

[sreinhardt]

Not a bad point either, with everyone else using the default nagios@ or nagios in the subject, I would not be surprised if they were specifically filtering for that.

[GldRush98]

Didn't help.
I've even gone as far as to try bouncing the alert off a gmail server. After setting up the fowarding number and a filter, the alert hits gmail, it gets forwarded to at&t, and then poof. It never hits the phone. What's even more maddening though is if I go in and manually click forward on the message in gmail and forward that, it will get to the phone. I feel like I'm taking crazy pills here.

[scottwilkerson]

Didn't help.
I've even gone as far as to try bouncing the alert off a gmail server. After setting up the fowarding number and a filter, the alert hits gmail, it gets forwarded to at&t, and then poof. It never hits the phone. What's even more maddening though is if I go in and manually click forward on the message in gmail and forward that, it will get to the phone. I feel like I'm taking crazy pills here.

Actually what you describe sounds like at&t is filtering messages from [email protected]. I say this because if you have it auto forward at gmail, the sender will be the same as the original,however if you click the forward from the inbox, the message is being sent from the gmail account....

If it was me I would contact at&t and raise hell.... But, make sure the email address [email protected] exists and is valid, because I have seen them reject messages because the domain didn't actually exist, using local domains, etc...

[isadmin]

I went through this last year and felt the same way...
try also changing the MMS template your using. I cut mine way down.

%type% Host Alert

Host: %host%
State: %hoststate%
Address: %hostaddress%
Info: %hostoutput%
Date/Time: %datetime%

Respond: %responseurl%

%type% Service Alert

Service: %service%
Host: %hostalias%
Address: %hostaddress%
State: %servicestate%
Info:
%serviceoutput%
Date/Time: %datetime%

Respond: %responseurl%

[isadmin]

and as Scott said our email send from address of [email protected] is a valid email address on our network.

[scottwilkerson]

I went through this last year and felt the same way...
try also changing the MMS template your using. I cut mine way down.

%type% Host Alert

Host: %host%
State: %hoststate%
Address: %hostaddress%
Info: %hostoutput%
Date/Time: %datetime%

Respond: %responseurl%

%type% Service Alert

Service: %service%
Host: %hostalias%
Address: %hostaddress%
State: %servicestate%
Info:
%serviceoutput%
Date/Time: %datetime%

Respond: %responseurl%

Yes, this could cause issues as well. Believe it or not, the major carriers do infact have "spam" protection for SMS/MMS and you could be getting caught in the "spam filter". the tricky part is figuring out what is triggering it.

On one of my phones, I seem to get everything, on another, if I have the systems email address set to the default nagios@localhost I will never get it.

I know it can be frustrating, but sometimes it is best to reach out to support at the carrier and explain the issue and have them dig into it.

[jvanbooven]

Figured out the problem, and how to fix it, at least if you use the PHP Mailer in Nagios XI.

I’ve been working on this issue with AT&T since June, and was escalated through many tiers of support in an effort to determine the cause. Ultimately, after working with Paul Mason, Principal Technical Architect, MMS Messaging (Tier 4) in their Operational Certification & Advanced Technical Support department, we have found that AT&T’s Nokia MMSC/NEMS platform is dropping these messages due to an RFC compliance issue in the email message header.

Specifically, part of the message headers appear like this:

Code: Select all

--b1_45a70008b4cc38472cc7e640786c55f6
Content-Type: text/plain; charset = "UTF-8"
Content-Transfer-Encoding: 8bit

However, the spaces in ‘charset = "UTF-8"’ are not allowed per the RFC. That section should appear as:

Code: Select all

--b1_45a70008b4cc38472cc7e640786c55f6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

We worked with Nagios support, and they have indicated that the issue has been corrected and will be included in the next release. In the interim, if you want to fix this on your own instance, you can modify the file /usr/local/nagiosxi/html/includes/phpmailer/class.phpmailer.php line 1282 (might be different on your system but should be close), which is where the extra spaces are added. The following line:

Code: Select all

 $result .= sprintf("Content-Type: %s; charset = \"%s\"", $contentType, $charSet);

should be changed to:

Code: Select all

$result .= sprintf("Content-Type: %s; charset=\"%s\"", $contentType, $charSet);

Now, we can finally use mms.att.net instead of txt.att.net. Message formatting is sooo much better when sent through mms.att.net

[hsmith]

Thank you for posting this! I hope it can help some people out that have the issue.