I was wondering what some of the biggest programming mistakes people have made involving mass mailing, spamming, testing or email coding in general were.
(I've posted mine below...)
I was wondering what some of the biggest programming mistakes people have made involving mass mailing, spamming, testing or email coding in general were.
(I've posted mine below...)
Back in my younger days working as a co-op for the company that I currently work for, I thought it would be funny to prank one of the developers with a spam script using ASP and CDONTS. It had a simple form and an entry to loop the number of times specified. I thought it would be funny to send him 100 emails near the end of the day, on a Friday before he was going on vacation.
It was definitely funny, not so much for him though. Not incrementing my loop correctly caused the script to run until timeout. Upon receiving the standard ASP script timeout message, I tested it several time. Luckily everyone at the company has a great sense of humor, and my boss was more upset that I didn't increment my loop correctly instead of the fact that I overwhelmed our dev server, our mail server, and rendered a co-workers mailbox completely unusable.
Like most major mistakes I've made, I will never live down the fury of TraviSpam.
A colleague (seriously) of mine had some code that emailed support whenever an error occurred on a 'beta' application that was being developed, this is all a good plan except for two things.
This resulted in a very large (> 100,000) emails being sent one weekend much to the horror of the email server admins.
PS: Although the question is on the surface (arguably) a little silly there are a lot of potential answers to this question that could teach people things about throttling/bouncing and how cross server admins can get when you get this stuff wrong
We implemented a mail queue for a newsletter system. The reason why we wanted this mail queue was to be able to personalize emails and also to sort them by domain etc. to send them out in groups to the designated mailserver. So for example, we'd sort by domain (e.g. aol.com) and then connect to the domain's MX to deliver.
We did a couple test runs and the biggest involved sending 30000 emails to a catch-all box to test.
In the process two things happened. I had not thought about the size of those emails in the queue and my test run filled up the HDD of a production servers with emails. While we could live with that for a while (backup system came in handy), it then filled up the queue of my mailserver with 30000 emails. Which led to massive delays for all people hosted on that server (~100 different clients). =)
This was six or seven years ago, when 15 GB was considered much.
I wrote a messaging system that went to the database to get a bunch of messages however my newb skills decided that the return of the next collection should be in a try/catch block so when the database went down it returned the same list over and over. This happened at 1am in the morning and was caught about an hour later. However it managed to send out 10,000+ messages to 200 or so customers.
The best bit? They were text messages and the customers were charged 20 cents for the privilege of receiving each one :)
Had to work closely with the local telcos to get that fixed up
I haven't had a problem so far, but that's because of ONE thing: I wrap the mail sending code in my own lightweight library, then I use that library to force every piece of email sent (this is at work, internal, so it's not a big deal) to be BCC'd to me. That way I'll know for sure if I've started spamming people uncontrollably, because I'll receive it too.
When I was in college (~1996), I worked at a bed and breakfast book publishing company. They had collected a mailing list through one of netscape's programs. At the time it was about 100,000 opt in users. The newsletter was about upscale properties, fine dining and living. I wrote some scripts to automate subscription/unsubscriptions and other admin tasks. Due to a bug in my code, a message was sent to the whole list. The body: 10,000 verified email addresses (some spammers lucky day). That wasn't the worst part. The subject: "Lord Byron is the biggest pimp since superfly"
I still shudder when I think of those days. I learned a good lesson, any testing/machine bound code should say "TEST". That stuff might get out to customers and make a bad situation HORRID.
Not my mistake, but a common enough one.
We had a ticketing system that would automatically send a 'We've received your message, here's your ticket number' e-mail whenever it got a message, which is fairly standard.
Another company had set up their system to reject mail with a message that essentially said 'We're not going to deliver your message unless you click on this link to prove you're human' (which is a horrible idea and trivial to bypass). They also, in this message, did not set the appropriate in-reply-to headers, they just generated a new e-mail and included the old subject/body in it. Also, the link in their e-mail didn't work.
End result? They sent us an e-mail, and we sent them a message saying we got their message and had generated a ticket. We then sent them an e-mail saying we got theirs. They replied, saying they wouldn't allow our message through without us clicking on the (broken) link. Since this was a new thread, we sent them a message saying we got their e-mail and generated a ticket.
Since I didn't have access to the backend to block their server, and since it was the graveyard shift, I had to write a python script to delete the tickets from the system and run it every few minutes, lest our system be completely drowned out. Our ticket counter increased by several thousand that night.
I sent an e-mail to my boss, who had the ticketing system delete any messages from them.
Allowing a . in the name of the recipient, which apparently is not allowed
Peter.Morris <[email protected]> == invalid
Peter Morris <[email protected]> == valid