Recently, I got a call from one of my local business clients about some issues sending emails. Since my voicemail translate service doesn’t always do a great job with phone numbers, I used the phone number I had saved in my contacts and received the following message from AT&T:

At no additional charge AT&T can help you find a similar business in the same area, since the number that you called is not in service. Please stay on the line for alternate businesses.

[…]

To connect to _____ Press 1….
To connect to _____ Press 2….

It was then that I recalled that this client had recently switched from using AT&T for phone service to Spectrum/Time Warner and the number I had saved was one of their old office extensions.

So, it seems that after you cancel your business phone service, AT&T hijacks the number to use it as a pitch for connecting you to a competing company. This seems like a pretty crappy business tactic and it would be interesting to see what their incentive is for squatting on canceled business numbers.

I would imagine the businesses they listed, which weren’t relevant at all to who I was calling btw, are paying for some sort of marketing service with AT&T, as the alternative is that AT&T is just trying to punish businesses that switch services.

I think one take away from this is that if you have a phone line through AT&T Business, or probably other Phone Service Providers, make sure to transfer that phone number and then cancel it. Otherwise, AT&T is going to use it try to hijack any of your business clients that might have the old number saved.

Advertisements

As (almost) anyone in the IT field knows, coffee is our lifeblood. To that end, I’ve gone through a number of iterations in how I prepare my coffee. Of course, the drip method was my introduction, followed by the french press, cold brew, and then currently the pour over. While I do still make cold brew and honestly prefer it over pour over, partly due to the convenience in the morning and the reduced acidity, I’ve been more consistently doing the pour over method for the last year, with cold brew sprinkled in periodically.

Over the years, I’ve significantly cut back on the amount of coffee I drink, going from 6-8 cups each day, down to only one large one in the morning. And, while there have been a number of different methods of preparation I’ve tried, the one constant was always sugar and, admittedly, a bit too much of it. More than a few heaping teaspoons almost always went into my morning cup of coffee or, when using cold brew, I would use sugar water in order to make sure it diluted properly.

However, for the past six months, I’ve managed to beat that and have been drinking my coffee black. It started on a week long trip where I was with several others that drank it black and so decided to give it a try. Since then, I’ve not added any sugar to my coffee, aside from a few Mocha drinks here and there purchased when on the road.

I have gotten to where I really enjoy the coffee taste by itself and haven’t really missed the sugar, although to be fair I do still usually have some sugar cereal in the morning, so have not cut it out completely. Interestingly, I recently got some Starbuck’s mocha drinks, which in the past I’ve always enjoyed. They were on sale at the big box store, so I went ahead and grabbed a case. However, after drinking one in the morning, instead of my reasonably large cup of black coffee, I found it much too sweet and didn’t enjoy it as I have in the past.

While I certainly have much further to go in terms of reducing my sugar habit, I feel like I’ve made a big step in cutting it out of my coffee in the morning and, surprisingly, it was much less painful than I would of expected it to be!

If you have ever helped someone setup their email account on an iphone(or set one up for yourself,) you may have noticed that when you get to the Outgoing server section, it says Optional next to the User Name and Password fields.

However, if you want to be able to send emails, in almost no cases, is this information actually optional. A username/password is required to send mail for all mainstream providers, like Google, Rackspace, Microsoft, Yahoo, etc.

I’ve never seen a properly configured server setup that doesn’t require this information, as if it is not required and the server is public facing, then it means the server is an open relay, which would mean it is almost certainly being spammed and has a poor reputation among other email providers as a result of it. I would think that there are some cases, possibly when connecting over a VPN or otherwise doing some sort of authentication, where it might actually be not required, but in practice when dealing with a main-stream email provider, your username/password is required. Not being required and actually being optional would be the exception, not the rule.

I would say that I spend between 1 and 3 hours each year providing phone or text support to people that get all the way through their setup on their own, but then see Optional, don’t refer back to their email setup guide, and then leave it blank…only to wonder why they can receive email, but not send.

I think it would make things much clearer if this was removed or possibly replaced with more accurate placeholder text, like ‘Required by Most Providers’ or ‘Required by Most Providers to Send Email’ This would help the majority of people and then those with a non-standard setup, would still be able to leave it blank if needed.

For the past few months, I have worked on and off providing some basic maintenance on a site built using Laravel’s PHP Framework. Up until this week, I didn’t have to get too deep into the functionality of the site and most changes were CSS related or other design fixes. However, this week I had to do some work with creating some addition views/routes/models, templating, and a few other tasks, so had to get my hands dirty and learn a bit about how it works and I think I like it.

This isn’t my first time working with Laravel products, I’ve developed two User Frosting sites and as a result have a decent amount of experience using Laravel’s Eloquent ORM, which I’ve found to work well and be comparable to other similar products, like Zend or WordPress’s Database implementation, although(at least in regards to Zend) much simplier to work with. It even integrates with Mssql with only a few minor issues.

Based on these two experiences, the ORM and PHP Framework, I have to say that I really like their products and could definitely see myself using it for new projects where I don’t need all the functionality of WordPress, but also don’t want to start from scratch on the build. Like userfrosting, I can see it as providing a pretty great starting point for a lot of smaller projects. Obviously, it is a bit on the technical side, so isn’t a drop-in replacement for WordPress for people looking to build their own site without much technical experience, but it really is pretty great to work with and isn’t overly complicated. I think when I have some free time, getting a basic template setup, so that I can use it starting point for new sites, would be a good use of time.

Lazy Domain Squatters

January 30, 2017

As someone who owns a few domains, I periodically(at least once or twice a year) get emailed by a domain squatter that contacts me in an attempt to sell a domain that is similar sounding to one I already own.

For those that are not familiar, a domain squatter is someone that purchases a domain with the intention of selling it(or holding it and then selling it,) for profit as opposed to using it. For example, if the .com version of a domain is taken and the .net version becomes available, a squatter, likely through the use of automated services/programming, may scoop up the .net version when it expires and then attempt to sell it to the .com owner at much higher than the likely $10-60 it cost them to purchase it.

So, when I received an email with legal jargon offering to sell me the .com version of a domain I already own, I almost tossed it in the trash, as I typically do when receiving these sorts of emails. However, for some reason, I decided to check the whois registration anyway and was surprised to find that the domain had fully expired and was available for purchase at regular rates.

It turned out that this lazy domain squatter was trying to sell me a domain, at an exorbitant rate, that they didn’t even own. They were making the minimum investment, an email, in the hopes that it would pay out, without even owning the domain.

I suppose this could just mean their automated tool is broken, but I like to think it is a lazy squatter hoping to make a quick(and cheap) buck, with little to no monetary risk.

While I still recommend not responding to or legitimizing domain squatters and their quasi-extortionist tactics, as unless you are Google, Paypal, or Amazon, you really don’t need to own every iteration of your domain name, if you get an email from someone trying to sell you a domain that you want, it is worth at least checking the whois to see if it is available for purchase!

As I’m sure you are aware, the April 27th deadline to switch off of Mandrill(or upgrade to a paid Mailchimp + Mandrill account) is approaching quickly. I’ve been using Mandrill for projects for some time now and overall have really liked the service. Its Magento/Mailchmip integration is really cool and painless and for the most part, deliverability has been fairly good.

However, back in February, Mandrill pivoted and announced that they were redoing their system to require all Mandrill accounts to have a paid Mailchimp account going forward. They gave users a rather short notice to either start paying for a Mailchimp and Mandrill account or switch to a different service.

I completely understand needing to charge for a service and would of probably been fine paying a monthly fee to use Mandrill(especially for its Magento integration,) forcing all my clients that are using it into a paid mailchimp account, especially when many use other services like iContact/Constant Contact/etc, didn’t sit right with me.

The Mandrill Pivot

Prior to February, Mandrill was billed as an:

Email delivery API from MailChimp

Mandrill is a reliable, scalable, and secure delivery API for transactional emails from websites and applications. It’s ideal for sending data-driven transactional emails, including targeted e-commerce and personalized one-to-one messages.

And, this is how I used it…as a way of ensuring better email deliverability than you can get using a random hosts sendmail functionality. However, the pivot resulted in the following new description:

Transactional Email for MailChimp

Mandrill is a transactional email API for MailChimp users. It’s reliable, powerful, and ideal for sending data-driven emails, including targeted e-commerce and personalized one-to-one messages.

So, as Mandrill was moving away from their initial use-case, I decided to also move away from it. Of all the people who I have using Mandrill, only one decided to stay with it and we may revisit that this week given how well Mailgun seems to work. In this case, the client actually used Mailchimp w/paid account already, so it wasn’t a big jump to also pay for Mandrill.

Transitioning to Mailgun

I suppose as a glutton for pain, I moved to yet another third-party service, this time choosing Mailgun, which was acquired by Rackspace several years ago. My reasoning for not wanting to roll my own transactional service, use the server’s sendmail tool, or just use SMTP on one of my email servers is mainly due to deliverability and, to a lesser extent, tracking/logging of clicks, opens, messages, etc. Of course, this could backfire if/when Rackspace decides to shut this down, but hopefully they will just eliminate the free version and convert it’s user’s to paid if that happens…not do a complete pivot like Mailchimp.

Overall, the transition has been painless and I actually like the web interface a lot more than Mandrill. It has a sane way to search the logs, SMTP responses and error codes are reported in a better and easier to understand fashion, and setup was easier. It feels like a much more mature web-interface.

Similarly, the PHP api was very easy to get working and I switched out all my Mandrill send mail functions to use Mailgun in no time at all. If anything, it is a bit simpler than Mandrill’s api. A couple of my sites were also using a WordPress SMTP plugin to send wordpress emails and switching those over to Mailgun’s SMTP offering was also painless.

First impressions of the service, website, and api are that it is a much better product than Mandrill. I’ll reiterate my hope that if it ever gets to the point that offering it as a free service doesn’t work out, Mailgun does a sane pivot to paid accounts, I would happily pay at this time.

Mailgun vs Mandrill Deliverability

I have not had any issues yet, although don’t have that much data. I will revisit this post in the coming months once I have been using it for longer and have more data to play with.

I imagine it can not be any worse than Mandrill, which sometimes silently failed, reported mails as sent that were not, and didn’t always properly report SMTP codes.

I run Arch on an older Intel Dual Core PC as a media center, which uses a pretty old, but relatively high memory Nvida Card. After upgrading Arch, I ran into a bug with Nvidia’s legacy 304xx driver and the latest kernel, which prevented XFCE/Xorg from properly starting.

The bug, aside from just the obvious no XFCE, was:

modprobe: ERROR: could not insert 'nvidia': Unknown symbol in module, or unknown parameter (see dmesg)
dmesg

nvidia: Unknown symbol mtrr_del (err 0)
nvidia: Unknown symbol mtrr_add (err 0)

After a bit of digging, I came across several bugs on the topic from various distros, including an Arch one bug report, which indicates that the bug was introduced in Nvidia 304.128 driver on Kernel 4.3.

Per the bug, I found the easiest way to fix it was to just enable the Arch LTS Kernel, which uses an older version of the Linux Kernel, at the time of this writing 4.1.16-1, which works a bit better with legacy hardware.

Warning: The below involves changing your grub settings, so use caution, make backups, and as with any time you mess with grub, you should be comfortable booting to alternate media(like a live CD) if something goes wrong.

1) First, install the LTS Kernel, LTS Headers(optional,) and LTS Nvidia Driver. Depending on your hardware, you may need other LTS software like if you run an older Realtek network card.

pacman -S linux-lts linux-lts-headers nvidia-304xx-lts

2) As root, make a backup of your /boot/grub/grub.cfg file

cp /boot/grub/grub.cfg ~/grub.cfg.bac

3) Update /boot/grub/grub.cfg to use the LTS Headers(again you should be comfortable fixing with a Live CD before messing with grub)

In the first grub menuentry section, probably titled ‘Arch Linux,’ find the two lines(which will probably be a bit different depending on your install):

linux   /vmlinuz-linux root=UUID=xxx-xxx-xxx-xxx- rw  quiet
echo    'Loading initial ramdisk ...'
initrd   /initramfs-linux.img

Add ‘lts’ to both the linux and initrd lines as shown below, so that they read /vmlinuz-linux-lts and /initramfs-linux-lts respectively:

linux   /vmlinuz-linux-lts root=UUID=xxx-xxx-xxx-xxx- rw  quiet
echo    'Loading initial ramdisk ...'
initrd   /initramfs-linux-lts.img

4) Reboot your system and if all goes well you should now be able to get your display working. If your system doesn’t boot at all, you can revert your grub.cfg to the backup you made. Otherwise, you may need to do a bit more troubleshooting.