MMS to Email is delayed by 24 hours or more

MMS to Email is delayed by 24 hours or more SearchSearch
Author Message
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 14
Registered: 12-2012
Posted on Wednesday, May 01, 2013 - 10:03 pm:   

We have a problem when Sending MMS to email, in that it takes upwards of 24 hours for it to go from NowSMS to it's final destination. We have the SMTP Smart Mailer enabled, but I suspect it tries for over 24 hours to send before it's handled by some other protocol.

Any insight on this?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4458
Registered: 08-2008
Posted on Wednesday, May 01, 2013 - 10:33 pm:   

Hi Jeremy,

This is a common issue that can be resolved with a configuration fix.

If you look at the MMSCOUT directory you will find a large number of files. They are what is causing the processing delay. And they are most likely triggered by an inbound MM4 connection that is not paired with an outbound MM4 Ack Routing.

Your MM4 partner is requesting acknowledgments for each submission, but the MMSC cannot figure out how to route the acknowledgments back to the partner.

Each MM4 connection has an inbound connection defined under "MMSC VASP", and an outbound connection defined under "MMSC Routing".

Check all "MMSC VASP" definitions that are using MM4, and make sure a "VASP Ack Routing" connection is defined.

After doing this, you still need to manually delete files from the MMSCOUT directory to restore normal performance (as it tends to take too long for the MMSC to error large numbers of them out).

With the MM4 Ack Route setting in place, the problem should not reoccur.

We have made changes to the next release to prevent problems caused by MM4 Acks when a pairing is not defined. And there is a stable interim release available at http://www.nowsms.com/download/nowsms20130401.zip.

However, I would recommend attempting to correct the configuration issue instead of updating at this time. The update does not generate MM4 Acks in this scenario. However, there are many MM4 implementations that resend messages if they do not receive the MM4 Ack, so it is better to fix the configuration to properly process the MM4 Acks by pairing the "MMSC VASP" with the "MMSC Routing". After you have done this, monitor the MMSCOUT directory for several days, looking for a build up of queued messages ... there should only be e-mail messages, not system messages with a subject line of "MM4 Acknowledgment".

--
Des
NowSMS Support
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 15
Registered: 12-2012
Posted on Wednesday, May 01, 2013 - 10:53 pm:   

We corrected our MM4 Acks a few months ago, but there's still a backlog of files in there. These are all .RFC and .INI file pairs, just over 5,000 files total; There's no MM4 Acknowledgments.

It looks like it's still trying to resend those messages. While I'm pretty sure these files won't get to their final destination ever (and would be fine to delete) are there any other repercussions to doing so? Would it be better to move these to another place for now in case we have to resend?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4459
Registered: 08-2008
Posted on Wednesday, May 01, 2013 - 11:00 pm:   

There is no problem at all deleting (or moving and then moving some back) these files.

INI files can be permanently deleted (will be recreated if RFC file is moved back).

Are these all legitimate looking emails or is there some pattern to them?
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 16
Registered: 12-2012
Posted on Wednesday, May 01, 2013 - 11:24 pm:   

Some of these look legit, others just say "ERROR: ERROR: ERROR: [...]" over and over, others are mostly blank. A few of them ARE failed MM4 acknowledgments.

Some common examples:
To: Mailer-Daemon@mms.unionwireless.com
From: Mail Delivery <Mailer-Daemon@mms.unionwireless.com>
Subject: ERROR: ERROR: ERROR: ERROR: ERROR: ERROR: ERROR: Multimedia Message
------------------
Message could not be delivered to Mailer-Daemon@mms.unionwireless.com

To: system-user@localhost
From: Mail Delivery <Mailer-Daemon@localhost>
Subject: ERROR: MM4 Acknowledgement

Message could not be delivered to system-user@mm4.inphomatch.com
------------------------
From: 13075551234@mms.unionwireless.com
X-MMSCSMTP-RCPT-TO: some_user1@aol.com
To: some_user1@aol.com
X-Mms-Message-Type: m-retrieve-conf
MIME-Version: 1.0
X-Mms-Mms-Version: 1.0
Message-ID: <20130421/12/68F68344@mms.unionwireless.com>
Date: Sun, 21 Apr 2013 12:30:56 -0600
Subject: Multimedia Message
Content-Type: multipart/mixed; boundary="--mime-boundary-mms-message-68F68344"

This is the preamble of a MIME multipart message.

----mime-boundary-mms-message-68F68344
Content-Type: text/plain; charset="us-ascii"
Content-location: text_0.txt
Content-ID: 0
Content-Transfer-Encoding: quoted-printable

[PERSONAL EMAIL TEXT HERE]
----mime-boundary-mms-message-68F68344--


After we moved these files, we retested and got an immediate response. Is there anyway to set a maximum retry limit for these files? I suspect We'll have to do a weekly cleanup for this folder so that it doesn't happen again?}
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4460
Registered: 08-2008
Posted on Thursday, May 02, 2013 - 12:32 am:   

I need to investigate further, but there does seem to be some sort of error loop.

I thought we had made this a default setting, but there is a setting that should stop the error loop...

Edit MMSC.INI, and under the [MMSC] header add:

SystemUser1=mailer-daemon

This will stop error loops involving the mailer-daemon address (which is used as a from in auto generated errors).

Can you send a ZIP with some of these messages, so I can better understand what is triggering the error loop?

Send to nowsms@nowsms.com with Attention: Des in the subject line.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4461
Registered: 08-2008
Posted on Thursday, May 02, 2013 - 08:41 pm:   

Hi Jeremy,

Do you have RemovePlusFromEMail=Yes set in the MMSC.INI file?

I believe this is one of two factors triggering the problem.

Essentially, a mistake is happening when e-mail delivery fails for an MMS to e-mail and RemovePlusFromEMail=Yes is set.

The resulting non-delivery message should go into an internal processing queue, but the sender phone number is not properly recognised so an error is mistakenly generated in the outbound SMTP queue.

This eventually triggers an error loop ... error messages don't multiply, but each time a mail message exhausts retries and is removed from the queue, a new error mail message is generated to take its place. Essentially this means that you are left with one message in the queue for every failed MMS to e-mail ever sent until they are manually removed.

This is a major problem, and I have made it a priority for our engineering team to address. However there are work-arounds, as both cause and subsequent effect are triggered by issues somewhat specific to your situation.

If you can remove RemovePlusFromEMail=Yes from MMSC.INI, this is the best work-around. (It does change the outbound e-mail address which may be an issue for you.) This will stop the auto generated error e-mails from ever being generated into the outbound SMTP queue.

An alternate work-around is to add the following to your MMSC.INI:

[MXLookup]
mms.unionwireless.com=127.0.0.1:25

If your MMSC is listening for SMTP on a port other than 25 (I know you use it for MM4 and may be using an alternate port), change :25 in the above example to the correct port.

This will circumvent the MX record lookup when the MMSC has an e-mail message for an address @mms.unionwireless.com.

This setting will prevent error loops, because even if you end up with an auto-generated error to Mailer-Daemon@mms.unionwireless.com, the MMSC will accept it via SMTP and silently discard it. (You may end up with stuck messages being retried for 24 hours, but never errors from & to Mailer-Daemon when this setting is enabled.)

Let me know if you need clarification on either work-around.

Unfortunately the retry setting cannot be reconfigured. Hard SMTP errors (5xx series, unknown recipient) are failed immediately, but soft failures are retried for 24 hours (with progressive delay between retries).

--
Des
NowSMS Support
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 17
Registered: 12-2012
Posted on Thursday, May 02, 2013 - 09:26 pm:   

I've removed that setting from the MMSC.ini file, and I'm not seeing anything else queue up for eternal retries.

Thanks again for your help, Des!