Java Zen:Thinking Out Loud Monday, 2025.09.15 
The whole point of design is that you have different goals that you need to
resolve. Want to design a trashcan for street corner? You have to make it light
so it can be emptied easily. You have to make it heavy so it won't blow away.
You have to make it big so it will hold lots of trash and the trash won't blow
out. You have to make it small so it won't take up too much space. You have to
make it easy to throw trash in so people don't miss and litter. You have to make
it hard for trash to get out so when it's windy the street doesn't litter
itself. Design is all about making hard choices and, hopefully, sometimes,
hitting upon elegant solutions that solve conflicting goals. But when you can't
solve conflicting goals, you have to be smart enough to decide which goal to
solve, and not just be a lazy punter.

		Joel Spolsky, "Why Religious Wars are Stupid" on w

2008.04.27

Mattress In The Mail

Would you send a mattress to someone via the U. S. Postal Service? Doubtful. Mostly because it’s just too darn inconvenient, on the front end, to stuff it into an envelop and attach all that postage. So, nobody does this. And think of the effect on the back end with the recipient? Their mailbox would effectively be locked. No place to put any of the other mail the postal carrier may need to deliver for you.

Yet, people send mattress via email all the time. This is so because the front end effort is negligible, but the back end effect could be just as unpleasant as attempting to wrestle a mattress out of your snail mailbox.

I had a problem brewing with my mail server for the past six weeks. It went unnoticed until the server started sending notices the vendor’s bandwidth limits were close to being exceeded. Since early March and up until April 23rd, there had been a message with an attachments exceeding 10 Mb sitting in my primary mail server’s queue. Fetchmail attempted, every 5 minutes, to retrieve the message to a secondary mail server running postfix. Fetchmail would pull the 10+ Mb message down to the secondary mail server and pass it on to postfix at which point postfix would reject the message because it’s 10 Mb attachment per message limit had been reached. And on this went every 5 minutes. The kicker came on April 23rd when an email newsletter I had, until now, subscribed to sent a 30 Mb video as an attachment!

Now things were getting ugly. For a brief period, the primary mail server was down (This was the first sign I had there was trouble.)

The total monthly traffic for this server normally runs about 200 Mb, far below the allotted 75 Gb set by the vendor. With these two stuck emails, the total bandwidth consumed by April 24th had reach 65 Gb. All this due to fetchmail retrieving these two messages with a combined size of 40 Mb every 5 minutes. After FTP’ing these messages off the mail server, the storm abated.

And sanity returned to email land.

Two lessons here.

Lesson one was for me. The two mail servers have been reconfigured to handle this situation more gracefully as this is likely to happen again. Why? Because lesson two isn’t likely to catch on: If you have a funny/interesting/whatever video for your friends to see, consider sending an email with a link to the file and not the file as an attachment. Unless you know the recipient has an email server that works like this:

Otherwise, nobody likes pulling a mattress out of their mailbox.

All content copyright © 1994 - Gregory Paul Engel, All Rights Reserved. The content or any portion thereof from this web site may not be reproduced in any form whatsoever without the written consent of Gregory Paul Engel. Queries may be sent to greg dot engel at javazen dot com.

No posts for this category or search criteria.