Barnes and Noble SMTP Follies
In this post, the author discusses issues encountered with Barnes & Noble’s email service, specifically related to SMTP configurations. He outlines the frustrations of dealing with their customer support and the complications that arose from system incompatibilities. The post highlights the challenges of integrating with third-party services and offers insights into the broader implications for users relying on specific tech solutions.
Generated by Azure AI on June 24, 2024An order from BarnesAndNoble.com wasn’t delivered after 10 days, so yesterday I went to their site to find out why. I found a customer service form, and submitted it with my name, email, order number, etc. I got a confirmation page saying that the issue had been logged.
Then, today, I get this:
This is an automatically generated Delivery Status Notification. THIS IS A WARNING MESSAGE ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. Delivery to the following recipients has been delayed. service@barnesandnoble.com
Could it really be that a company as big as Barnes and Noble is depending on SMTP email for something as critical as their customer service system?
This notice tells me that the form just generated an SMTP email that was sent to that customer service address. Indeed, the email it generated was attached – it was my form data with User-Agent and IP tacked on (it looked suspiciously like a FrontPage WebBot email, actually).
Was it logged in a database? A CRM system? Doesn’t seem like it. It seems like Barnes and Noble honestly just dumps the form data to an email, tosses it at an SMTP server, and crosses its fingers.
Email is a fundamentally untrustworthy mechanism these days. For smaller companies and non-critical information, it’s fine. But for a Fortune 500 company to run a CRM-type application off it seems awfully risky to me, as evidenced here.