Recently - a week or two -- previously accepted messages through vtext.com are rejected as too long. They are NOT too long, and similar messages have worked for years. Of several messages of identical length (differing content), most go though and a few are rejected as 'too big" What is happening?
- These recipients of your message have been processed by the mail server:
[email address removed per the Verizon Terms of Service]; Failed; 5.3.4 (message too big for system)
The text of this message was 70 characters. Adding the sending email address (Verizon's instructions on this are opaque and confusing) brings it to 98.
We're sorry to hear you've been having trouble with sending VText messages and would like to take a closer look into this with you, jimhetland. Just to confirm, are you sending multiple messages or just one message at a time? Does this happen every time you send a message or is it sporadic? Does this happen with more than one person? -Danielle
Thank you for your concern.
I send the messages from a program running in my desktop, and almost exclusively to my own Verizon cell phone (the program alerts me to various events). The number varies but is probably on the order of a dozen per day, spaced pretty randomly throughout 24 hours, and only rarely more than one at a time. When there are two or three, they are a few seconds apart, and to my knowledge, none of those has failed.
To be clear, the bounce only happened a few times, spaced all around the clock, and I do not have enough information saved to tell you if they took the same path to the destination. I am not certain what I may have deleted or discarded, but it appears only a handful, fewer than six, have failed as described, and all between about 2/3/23 and 2/7/23;; This is the most recent:
Reporting-MTA: dns; cmx-alt-rgout001.mx-altice.prod.cloud.synchronoss.net
Received-from-MTA: dns; DEV3 (47.20.45.xx)
Arrival-Date: Tue, 7 Feb 2023 13:15:18 +0000
Final-Recipient: rfc822; [cell#]@vtext.com
Action: Failed
Status: 5.3.4 (message too big for system)
Remote-MTA: dns; vrz-sms.mx.a.cloudfilter.net
The rejection is clearly erroneous: the subject and body of the message referenced here totaled 72 bytes; the sender friendly name, which I believe is also counted, is 2 characters (the full sender address is 23). I understand the limit to be 160 characters.
If I can be of further assistance, please advise, and thanks.
I appreciate your response, and would be happy to help! Let's gather more information to get started about how these messages are being sent. Did you create a new message and send it and received this response (too big)? Was this message to one individual recipient or multiple recipients (one failed out of multiple)?
*Cheyenne
As I described, the messages are sent individually (I don't think multiple recipients are even possible). Some small number bounced in this way, while others before and after succeeded. It's very rare that messages come less than minutes to hours apart, and there were no consecutive failures.
Just to be clear, we're talking only about messages sent by email through vtext.com, not from a cell phone. And the rejection is from a Verizon server or cloud service, nothing close to me.
One guess: my ISP adds a number of scanner headers to outgoing email, and of course transit paths vary too, and it's at least possible that this increased the overall SMTP length (not the SMS length) past some hipshot limit imposed at the target. But since I cannot see the message at that stage this is only speculation.
Could you please send an example of the most recent message that you sent that failed (02/07/23 at 13:15:18)? Are these messages containing only text, photos, attachments, links, etc?
*Cheyenne
Are you reading these? The messages are a single line of text, typically about 70 characters. My sender does not keep copies.
I thought this might have been fixed, but I got another one today:
Content-Type: Message/Delivery-Status
Reporting-MTA: dns; cmx-alt-rgout001.mx-altice.prod.cloud.synchronoss.net
Received-from-MTA: dns; DEV3 (47.20.45.xx)
Arrival-Date: Fri, 10 Feb 2023 17:27:06 +0000
Final-Recipient: rfc822; [cell#]@vtext.com
Action: Failed
Status: 5.3.4 (message too big for system)
Remote-MTA: dns; vrz-sms.mx.a.cloudfilter.net
The only thing that matters here is the "Status 5.3.4" and the "Remote-MTA" line. Cloudfilter.net is a Cloudmark domain, presumably under contract to Verizon (cf. "vrz-sms") for spam filtering or the like, and it is rejecting some messages as too long when they are not. I'm guessing some messages accrete more "Received:" headers than others, or other kinds of detritus from the Internet, and Cloudmark has set a gate too small. The size gate is probably a good idea, but it's too small. That's the issue, I'm reasonably confident, and there's nothing I can change at my end that can make any difference, nor can my ISP (the "Reporting-MTA" that sent me the bounce message they received).
I did get a call from Verizon today, so thanks for that, and at least I know it's still being worked on, though I'm not yet convinced they have the right people working on it.
We know how important it is for the Vtext issue to be properly addressed. Yes, we've reviewed the messages here and understand that a ticket was opened for you recently. This would be the same route our Social Media team would take. Why do you feel the issue is not being handled correctly? Please keep in mind that a ticket can take 5 to 7 business days or longer to be completed depending on the issue and amount of tickets already being worked on. Please tell us how we can further assist.
-Rita K.
Thanks for asking. I know I sound impatient, and I do understand about workloads, priorities, all that stuff.
But it took me an hour on the phone to even reach someone who knew what vtext is. Then it moved to this forum, where I was asked about attachments, photos and such. For a service limited to SMS text messages, and where I had already described in detail what had occurred. First rule: read the post, THEN ask questions.
While you're at it, you can see about fixing this forum, which let me type my whole long response (ok, I got carried away) before asking me to login, upon which it discarded everything I had written.
OK, working on patience. And hoping I don't have to explain SMTP response codes to any more of your technicians.
I did mean the part about thanks for asking.
And just for followup: I haven't heard word one about this since the above, though it does appear the issue was corrected.
Start a new topic or ask questions in the open forum.
