This is the mail system at host smtpin-2.iphouse.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

<blogtest@iphouse.com>: permission denied. Command output: maildrop: maildir
    over quota.

Breaking this error down; the first part tells us what server issued the rejection. In this case it was the host “smtpin-2.iphouse.net” – the mail server responsible for receiving email for the email address blogtest@iphouse.com   The second part tells us who we were sending the email to, in this case it was sent to testblog@iphouse.com  The third part tells us the error type, as in a permanent or temporary error. A permanent error means that the email won’t be delivered. A temporary error means that the sending mail server ought to try again later.  In this case it says “Permission Denied” – that’s a permanent error. The fourth part of this error message tells us why the email was rejected, in this case it says “Command output: maildrop: maildir over quota”. What this means is that the service “maildrop” says that the Mail Directory (maildir) is over quota – the mailbox is full. What this means for us the sender, is that we shouldn’t bother trying to send that person anymore email until they clear out their overstuffed mailbox. There isn’t anything we can do about it other that calling that person up to tell them that their mailbox is full.

Here’s the next error bounceback:

Unable to deliver message to: <blogtest@iphouse.com>
Delivery failed for the following reason:
smtpin-2.iphouse.net[216.250.188.181] responded with failure: 550 5.7.1 black
listed URL host ***.********.net by .black.uribl.com

This has been a permanent failure.  No further delivery attempts will be made.

I did make one edit to this error message, I replaced the blacklisted URL with a bunch of asterisks (*). I don’t see any reason to give a spammy site any more traffic than it already has. OK, so let’s break this error down. The first part of this error message tells us who we were sending the email to, in this case blogtest@iphouse.com was the intended recipient. The second part tells us what server issued the rejection, in this case it was the server smtpin-2.iphouse.net – so it was the recipient’s mail server issuing the rejection, not the sender’s. The third part tells us what kind of rejection it was, and why it was rejected. In this case the error code was “550″ (I’ll go into error codes later), and that the email was rejected because it had a link to a website (the one I used ***** to hide), which happened to be on the blacklist “black.uribl.com”. The last part is just another note that this was a permanent error, in case you didn’t already know that that’s what a 550 is. What this bounce back message means for us the sender is that we had a link to a website in our email that a spam filter on the recipient’s mail server didn’t like. We’ve got a few options here. The simplest thing would be to send the person a new email, but this time not include the offending website link. If we think that the website in question should not be on this blacklist in the first place (mistakenly listed), then we can always go to uribl.com and request that the offending website be removed from their list. Not all blacklists let you do this, but plenty do – and as it so happens, uribl.com lets you request removals. Another option would be to contact the intended recipient to tell them that a spam filter of theirs is rejecting that link. The intended recipient could then follow up with their IT staff, or their ISP. I suppose the final option would be to try to “game the filter” by breaking up the link a bit. For example, let’s say that iphouse.com was blacklisted somehow. I could try sending the person a link to iphouse.com like this:  www (dot) iphouse (dot) com    A human reading this ought to be able to figure out your intent, whereas a spam filter might be tricked.

Here’s the next error bounce back:

<testblog@iphouse.com>: host smtpgrey-2.iphouse.net[216.250.190.161] said: 550
    5.1.1 <testblog@iphouse.com>: Recipient address rejected: User unknown (in
    reply to RCPT TO command)

The first part of this error message tells us who we were sending the email to, in this case testblog@iphouse.com was the intended recipient. The second part tells us what server issued the rejection, in this case it was the server smtpgrey-2.iphouse.net – so it was the recipient’s mail server issuing the rejection, not the sender’s. The third part tells us what kind of rejection it was, and why it was rejected. It’s another 550, so a permanent rejection. It was rejected because the User was Unknown. This means that the email address doesn’t exist. If you caught the mistake in the email address right off the bat, plus 10 points for you. I accidentally sent an email to “testblog@iphouse.com” instead of “blogtest@iphouse.com”. Oops. As a funny aside, I actually generated this bounce back message accidentally when I was aiming for another type of bounce back. It took me a moment to catch my mistake. I guess that’s what more coffee is for…..    Anyhoo, what this means for us the sender, is that we just need to send out a new email, but this time type in the correct address. If you’re absolutely positively 100% double plus certain that you didn’t make any typo in the email you sent out, go ahead and look for the typo anyhow. It’s really easy to miss certain things like a “,” instead of a “.”, or a letter out of place. If your double check doesn’t yield any typos, and you’re certain that the address is a valid one, you might want to contact the intended recipient to inform them that something is amiss regarding their email address.

1) If I’ve sent and received email from my friend for years, it shouldn’t get flagged as spam.

2) If I have their email address in my address book, their email won’t get flagged as spam.

3) If I avoid using certain words, my email won’t get flagged as spam.

None of these things are true. To understand why this is a tricky question to answer, it’s helpful to know a bit about what ISP’s are doing to filter spam. Most ISP’s have their own “custom blend” of what they do to filter spam, but it more or less boils down to using a combination of one or more of the following: Blacklists, Greylisting,  enforcing RFC’s, and more traditional Content Filters.

Blacklists can be based on all kinds of things. They can be lists of IP addresses that have been reported as sources of spam, lists of mail servers that have been found to be capable of being used as open mail relays, lists of URL’s that have been “spamvertised”, or any number of other things. Not all blacklists are the same. Some are very aggressive in what they list, and some are very conservative. The aggressive lists might block a lot of spam, but they are also more likely to have “false positives” – as in they blocked something that the recipient really did want to receive. Whereas the conservative lists might not have many false positives, but they’re likely to let more spam through.

Greylisting is when a receiving mail server issues a temporary error, which causes the sending mail server to re-queue the email and send it once more. Being able to re-queue an email is something that any RFC compliant mail server ought to be able to do. Greylisting can drastically reduce spam sent through “spam zombies” – home computers compromised by viruses that send spam out directly from the PC instead of through a mail server capable of re-queuing email.

RFC’s are, in a nutshell, the basic minimum standards for anything Internet related. Enforcing RFC compliance for mail can cut down on mail sent out from compromised PC’s/servers, and cut down on spam sent out from “sketchy” mail servers.

And lastly, content filters are the more traditional form of analyzing the content of an email to determine the “spamyness” of the email. Each spam filter system has its own “custom blend” of techniques to identify spam. Some of these criteria include; spammy words/spelling (\/1agra), format of an email (lot’s of CAPITAL/BOLD/etc lettering), lists of “spamvertised” websites, know spammer addresses, etc. Some filters use a feedback system that allows end users to submit examples of spam to train the filter.

Because blacklists and content filters are dynamic in nature, it can be very difficult to determine what it was at that exact moment that caused a particular email to be tagged as spam.