The MVgen team has been working hard to roll out cool new features as quickly as we can. Everyday we’re one step closer to seeing our tool grow into the app everyone thinks of when they want to create a music video. This past week, we got even closer still to that goal as well as working toward positioning ourselves for outside help. You may have noticed that Ads came in as of a couple weeks back, and user accounts are live at LONG last. Director and Hacker extraordinaire, John set them live — perhaps a bit before I was comfortable with — but that put a fire under me/us to make the user accounts piece as seamless and user friendly as possible.
We hit a major hurdle though as we decided to get more “professional” with things and a) get official @mvgen.com incoming mail to work, and b) have user account emails transmitted appropriately/securely.
Back on Nov 29th user accounts were sending properly, meaning they were TLS encrypted and not sent to everyone’s spam folder. This changed as soon as I began adjusting Postfix/Dovecot settings to get both incoming and outgoing mail working — at the moment we’re using gmail for SMTP, which is fine as long as we don’t hit their limit for number of emails sent out daily for a specific email address (1000 i think?). IF we ever get more than 1000 emails sent in a day, we’ll have to shift to a different method for SMTP, but like always, we’ll cross that bridge when it comes into view.
Right around Dec 1, email started not delivering and then also getting dumped into everyone’s spam folders. There’s a laundry list of things you have to do in order for google to allow you to use them as a SMTP relay, 85% of which I took care of back in October when I first started working on the email bit of MVgen user account setup. Even though I used the ISPs official documentation for setting up Postfix and Dovecot shit wasn’t working anymore. Suddenly, we started to get IPV6 PTR record errors (reverse dns) and lack of encryption messages and also that there wasn’t a valid PTR record for the mail server’s hostname? Some of this I was able to resolve by adjusting what was in our MX, TXT, and SPF records but there were still configuration issues.
I lost count of how many test emails I sent to myself and John and how many times I created new user accounts on mvgen.com to see if they would again be labeled as spam. I was led astray by sites like www.mxtoolbox.com, only to be saved by intoDNS.com. We signed up for things like dnswl.org and postmaster.google.com.
John ended up encrypting the outgoing message for new user within the front-end code, probably a good idea in the long run, and we went a couple rounds about whether to make the sender address the a valid gmail address or not. At some point in our testing, both a valid gmail and a perhaps not so valid domain email seemed to work. We eventually went with the former.
Truly, the biggest hurdle was the fact that he’d already setup mail on his VPS and it had worked at some unknown point in the past but he never really needed to use it regularly. And when setting up Postfix/Dovecot/MYSQL to work together emails, passwords and everything goes through Mysql. This in itself isn’t a bad thing but I came *this close* to switching to to another db because I couldn’t get dovecot to authenticate to mysql. It was impossible to do anything with mail until that part was fixed. Time and again I saw the same standard mysql authentication error in the mail.log. After about half a week I took drastic measures. There was nothing on google that was helpful. I’d reset mysql passwords and backed up and recreated the mail database to no avail. Nothing worked. And since it was the standard password error, there wasn’t any real detailed help available on google. This sad reality is something you’ll see a lot if you’re ever troubleshooting an issue that seems unfixable yet common. Nobody will help you because it’s assumed you’ve fat-fingered the username or password. In this instance, that wasn’t the case. However, there were a couple things I would have done differently in retrospect. 1. I would have started all over again with the mail database and user. 2. I would have named the username and db name the same thing via the handy menu in phpmysql. 3. I would have flushed privileges EVERY TIME I made a change to the database. I found out rather late in the process this was a crucial misstep.
After some final massaging of configuration files not only do mail messages get received by the MVgen staff successfully, the mail sent from the website isn’t sent to spam or un-encrypted. And it only took about a week of hand-wringing and hair-pulling. Jeezy petes. Now to move on to more interesting projects, there’s always something to do in a startup, right?
