This post is for any of my MessageLabs readers. I tried to send an email to my travel company today using my Gmail account (which I pop through Thunderbird). I got an NDR saying the following:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 553-Message filtered. Please see the FAQs section on spam
553-at http://www.messagelabs.com/support/ for more
553 information. (#5.7.1)
I went to that link and I didn't see any FAQ's but I did see a list of bounce messages which I could click on for more information. I clicked on the first link (553-Message filtered) and followed the instructions.
I don't really want to add myself to my travel company's approved client list, I'd just like this to work. Thanks.
Terry, you "must" use FCrDNS on all IP addresses. See http://tools.ietf.org/html/rfc1912 and http://en.wikipedia.org/wiki/FCrDNS. It's not just a good idea, it's the law (well, a standard, anyway).
Yes, email delivery used to work just fine without it, but then our inboxes didn't used to be full of spam sent by poorly-administered network nodes either.
Richi, you're probably right, but if Terry is mailing through Gmail's SMTP server, his first hop IP address should not need FCrDNS (it shouldn't need rDNS at all). It isn't clear what "using my Gmail account" means here.
You are correct, I'm mailing through Gmail's SMTP server, smtp.gmail.com.
Ah yes, sorry I missed the Gmail bit. Was dealing with being Slashdotted this morning.
Your fragment doesn't include any of the original headers, which would probably be underneath. When you checked for blacklists, did you use the Gmail IP address that connected to MessageLabs? That's the one you should be testing, not your IPA.
Yes, I left out my original message headers purposely, I wasn't sure I wanted to post them on the internet.
Received: by 10.114.211.1 with SMTP id j1mr100217wag.1177476328072;
Tue, 24 Apr 2007 21:45:28 -0700 (PDT)
Received: from ?198.18.132.215? ( [18.104.22.168])
by mx.google.com with ESMTP id z15sm64394pod.2007.04.24.21.45.25;
Tue, 24 Apr 2007 21:45:26 -0700 (PDT)
Everything's fixed now, I got the situation cleared up (professional courtesy). I simply thought it odd that I got the bounce-back.
BTW, when it comes to rDNS being used as method of identifying spam/non-spam, at least in our own filters the results are mixed. At best, these results are ambiguous. It may be a standard but apparently it's optional (ie, few people use it). We check for a reverse domain lookup and we apply a very small score to the message if it fails. It only hits in messages marked as spam around 58% of the time. If it were being used by spammers we would expect to see a much higher spam ratio.
To me, this implies that a lot of legitimate users don't have a reverse DNS. Of course, the other possiblity is that spammers are using it but our filters are simply missing it. While I grant that as a possibility, the false positives I have examined for this particular rule suggest that many legitimate senders do, indeed, have no reverse DNS.
Sadly, FCrDNS isn't as widely used as it should be, but I'd say that people are gradually getting the message.
Of course, very, very few anti-spam rules should on their own cause a message to be rejected. Even a SURBL hit could be a false positive.
> ... but I'd say that people are gradually getting the message.
Slowly but surely.
> Of course, very, very few anti-spam rules should on their own cause a message to be rejected.
Correct, and that's the way we do things. Spam rules are measured in parallel with other rules; if a rule hits and combined with other rules the message is marked as spam, it gets a spam hit. If the message is not subsequently marked as spam (combined with other rules), it gets a non-spam hit (as would all the others).
The way I measure performance on rules is to see how often they hit spam/non-spam relative to our filtering ratio. For example, we mark around 20% of our mail as non-spam (after blacklists). This means that about 80% of mail we content filter is spam. If a rule has a 99% spam ratio and we filter 80% as spam, then we know it's a very good rule that hits mostly spam (putting aside the question of false positives for the moment).
In the case of an rDNS, it's hitting 58% spam relative to the 80% spam ratio... a gap of 22%. That's quite significant which tells me that it is not highly correlated with spamming, particularly at such a small score. A rule that hits 42% of the time in only 20% of our mail stream is indicative of under-performance, at least to me.
Well, your NDR is better than that provided by most MS products which don't usually reference SMTP response codes... so exchange, outlook, hotmail, etc... no 55x message too big or 55x mailbox full or 55x user unknown or any number of other useful (or not so useful like this one) error messages.
So I don't see why a MS employee should be complaining or what exactly your original complaint was about...
The whole discussion of rDNS here is not applicable to your message bouncing (gmail) or even spam -- although rDNS is entirely wrong and messages should be rejected again not because they are spam but because their servers are misconfigured and should be corrected and fixed. So discuss rDNS in the context of proper server configuration... for example SPF may do some rDNS checks and it shouldn't be left waiting for some nslookup to time-out. AOL, Comcast, a few other large ISPs do reject based on no rDNS and it is ok for them to do so.
Next, as for your particular problem I notice lots of spam from even gmail (and noticed my account had lots spam there long ago) so I'm not surprised someone may have blackened the one IP address you where unfortunate enough to be given (on SB or PSBL etc), but if you tried again immediately, the message is likely to have been successful as it would have used one of the hundred other **-out-####.google.com servers they round-robin between and likely, you would have not had a problem the second through 100th time.
But looking at your "headers" now that you provided them indicate that you used 198.18.x.x which is reserved on the internet (for routers and testing and stuff) so perhaps MessageLabs saw that line as bogus and classified the message spam. Or we can see the external IP address is that of a Marriott so it isn't impossible for 10 other computers sharing the IP in the hotel to be trojans or infected and sending spam/viruses.
I would be interested in learning how it was fixed or since it was fixed to learn the original culprit... or did you just send the message again? Again, even if just resending the message didn't work, you could have just sent a message via gmail's web interface which obfuscates the client ip and probably been guaranteed to have been successful.
I saw this problem many times.
Messagelabs do a very poor job.
Spam filtering is difficult because you must avoid dropping
valid emails; messagelabs do not care and drop a lot of valid
emails. They do not tell you why; they just drop a random
selection of perfectly legitimate emails for no reasons
whatsoever. If you phone them to ask, they refuse to talk
to you. They often refuse to even talk to their customers.
They just don't care.
Avoid messagelabs like the plague.
HELP! I am not computer savy, but it looks like some website got ahold of some email addresses on my address book, and sent its own web info. about illegal meds. from Canada! How do I find out how it was sent and who actually received it? Should I place the transcript session of this "failed" emails on this board or how do I find out who actually received it and how to do damage control? Thanks much.