MvSMTP emails treated as SPAM

[wcw]

I have been pulling my hair out all morning on this. For years I have been able to send SMS messages to my phone using [email protected] from Miva Merchant using the MvSMTP.

All of a sudden about a week ago, the messages started bouncing back to my store's email address (the from address). They are simple text emails of very short length, i.e. name, phone, product codes ordered.

So I tested sending short text emails using my regular mail and also hotmail.com to the sprint message and they worked fine. So looking at the headers, the only big thing I saw that is different was the MvSMTP generated emails did not have a line for Message-ID: with a bunch of numbers and the sending server domain. The MvSMTP generated emails did have "X-Mailer: Miva v5.15" which the regular email program did not include.

Here is the error message "Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long."

So what is causing the rejection and how can we fix it?

[wcw]

Re: MvSMTP emails treated as SPAM

Well, miracle of all miracles. The bounces have been going on for about a week. Shortly after posting this thread, SMS messages started coming in. They were orders from yesterday that were apparently bounces but not in the queue too long, plus a bunch of test orders that I placed today. I don't know if it was a miracle or someone from Miva read this post and unstuck something. I feel like a mushroom; kept in the dark.

[wcw]

Re: MvSMTP emails treated as SPAM

Unbelievable. The emails are bouncing again. Hello hostasaurus. It was apparently fixed after I originally posted. Then it is broken again. Did you folks do anything on Aug 31 to get Sprint to accept them instead of bouncing them back?

[virtualkiwi]

Re: MvSMTP emails treated as SPAM

Some spam filters do reject emails without a message-id.

I have a line:

	<mveval expr="{'Message-ID: <' $ makesessionid( ) $  '@' $ g.sys:Domain $ '>' $ g.cr}" />

inside my mvsmtp tags. (To comply with the specifications, each new message should have a different id)

This seems to deal with a lot of messages that were getting rejected as spam.

The other thing I found that could cause issues but probably doesn't apply in your case is HTML formatted emails that are not constructed as a multi-part message with a plain text version.

[wcw]

Re: MvSMTP emails treated as SPAM

I'll look at that option to manually add it. But if this is a known problem with miva generated emails, I would think this is something that Rick or Jon needs to look at. Perhaps it should be part of the miva engine's mvsmtp function; either as an actual parameter in the mvsmtp or inserted on all messages.

Curious, you are simply generating a random string of characters. Here I thought that Message-ID had to be something tied to the email server that would return an authentication code indicating it was a valid send from that server. So is it just a number that means nothing and a spammer would include it if they were serious about getting their email out? Or by you including it in the outgoing email, the mail server stores it in some database on the mail server so it can be validated?

[nottheusual1]

Re: MvSMTP emails treated as SPAM

No - it's just a unique code, per the RFC's, and no two messages should have the same code.

Most servers stamp them as unformatted [email protected]. That's all the RFC requires.

[wcw]

Re: MvSMTP emails treated as SPAM

Hence, your use of makesessionid(). If you used system time/date, you could have duplicates. When an order is placed more than one email could be squeezed out in the same second.

What about the domain thing? Folks on hostasaurus are likely using localhost for their mail server. What do they put for the mail server's domain? I was looking at several legit emails I've received and that domain is not always the same as the "from" or "reply-to".

[nottheusual1]

Re: MvSMTP emails treated as SPAM

That can depend on how the mail servers are configured. Some servers send from the server's base IP and some are configured to send from the domain IP and some systems will send from many MXs - like if you had a "company" account with Gmail, etc., so the MTA will set the header based on any number of rules.

[wcw]

Re: MvSMTP emails treated as SPAM

I wish the miva folks would weigh in on this and discuss putting the message-id in with an engine update.

[nottheusual1]

Re: MvSMTP emails treated as SPAM

I make everything go through the domain server so we can use DKIM and SPF if it isn't going local - and the inbound side whitelists any Email from our store IPs, so that's never a problem. We send so much into the gaping black holes that are Gmail. Yahoo, Verizon, etc, that we're always really minding the P+Qs.

[alphatect]

Re: MvSMTP emails treated as SPAM

I just had a customer order confirmation email bounce back with:

"Remote host said: 550 Message SHOULD have Message-ID: but does not"

This is the first time I've seen this. The recipient is a university in Canada. They must have their spam filters set more tightly than most. Hopefully this doesn't become a trend. Please let me know if there is an easy fix.

Thanks!
Kyle Creasy, Alphatect

[wcw]

Re: MvSMTP emails treated as SPAM

Considering that Sprint (a very large ISP) is intermittently rejecting them and now a server in Canada is doing it, I think we have a trend. Hopefully, Miva will include it in the next engine update. Otherwise we may all wake up some day to find that all of our stores' order emails are being rejected due to no Message ID.

[nottheusual1]

Re: MvSMTP emails treated as SPAM

Honestly, I'm surprised it hasn't already happened. That's one of the most basic specs of Email's RFCs. Spamassassin, alone, runs 12 different tests on the message ID header.

[virtualkiwi]

Re: MvSMTP emails treated as SPAM

I wish the miva folks would weigh in on this and discuss putting the message-id in with an engine update.

Actually slightly OT, but compared to PHP, <mvsmtp> is pretty helpful. The mail() function in PHP doesn't even put in a from address. You have to add the from: header yourself, as well as the message-id header and pretty much all the other headers.
I guess <mvsmtp> has made mail handling too easy so that now all those spam filters out there are getting tough and expecting RFC compliant emails or else rejecting them, it's necessary to learn how to construct mail headers properly.
If you want to send HTML mails without them bouncing, things get a whole lot more interesting.

[alphatect]

Re: MvSMTP emails treated as SPAM

I just noticed that Roadrunner add a Message-ID to my incoming emails. I placed some test orders and was confused because a Message-ID was appearing on my order confirmation emails. This didn't make sense. But then I noticed that the Message-ID contained "mail.rr.com" at the end. So this tells me that Roadrunner is adding the Message-ID themselves.

I sent a few test emails and found that Roadrunner adds the Message-ID both ways (incoming and outgoing). I understand the outgoing. That seems correct. It's the incoming that doesn't make sense to me.

I also checked my shipping confirmation emails using Endicia/Dazzle. They do not contain a Message-ID before they are sent. So it seems that with any email that's auto-generated through a third-party software, there's a good chance of having no Message-ID. However, my FedEx Shipment Notification emails do contain a Message-ID - ending with "fedex.com". So FedEx generates the Message-ID before the ISP gets a chance to.