[Coco] Re: I receive "Undelivered Mail Return to Sender"
John E. Malmberg
wb8tyw at qsl.net
Sun Feb 27 15:34:40 EST 2005
Brian Goers wrote:
> Can someone tell me, Why do I have this in my e-mail sometimes?
With out the headers and the exact non-delivery message, it is
impossible to tell what you are seeing.
The SMTP protocol has two methods of indicating non-delivery.
The first is what almost all mail servers use. They terminate the
session with a SMTP reject code of either a 4xx series for a temporary
problem, and a 5xx for a permanent problem.
The second is that e-mail RFCs allow mail servers to accept e-mail to a
local storage for relay, and then generate a non-delivery message if
they can not relay it.
Unfortunately that RFC was from a more trusting time. Almost all
undeliverable e-mail is either virus or spam spoofing someone else's
Now almost all production mail servers will use the SMTP reject codes,
as it is the only non-abusive method of indicating non-delivery. This
means that the sending mail server will generate a non-delivery message.
With spam or viruses, the is no actual mail server, so no bounce gets
Any mail server that is accepting and then bouncing undeliverable
messages is effectively participating in a denial of service attack
against the mail servers of innocent victims.
So what you are seeing could be one of several things:
1. A fake bounce generated by a virus, in which case there was a live
virus in the e-mail.
2. A fake bounce used by spammers to trick you in to looking at the message.
3. A fake bounce by a clueless user of a product that claims that it can
bounce spam. Such bounces almost never go to a spammer, just to someone
4. A bounce from someone that has configured their mail server to bounce
undeliverable e-mail instead of using SMTP rejects.
> Also how would I stop it from happening?
It is unlikely that it came as a result of something sent by your computer.
You have three options:
1. Delete them.
2. Look up the I.P. address of the sending system, and then the abuse
address for it, and send a complaint to it.
3a. Submit the sending I.P. for open proxy testing if the rDNS indicates
that it is probably not a mail server. If the rDNS indicates that it is
probably a mail server, then submit it for open relay testing.
3b. If the rDNS indicates it is a dynamic address, then it is obviously
missing from the dynamic pool list your ISP is using, so find out what
it is, and submit it to them.
3c. Your ISP may do 3a and 3b for you if they are full service.
> My ISP has a spam blocker that looks like it is working OK. and I have
> a Virus scanner (AVG).
A virus scanner can only be trusted to detect virms that have been out
in the wild for over 8 hours at best.
Depending on what you are actually seeing, it could indicate if your
ISP's spam blocker is up to snuff.
My broadband ISP's content filter has never been able to detect spam
that is detectable by simple reliable tests.
The only thing that brought the spam problem even slightly under control
is when they put in conservative DNSbls and local blocking.
From the reports I have seen, the state of the art in effective spam
filtering is only available in using conservative DNSbls on the front of
the mail server which will remove between 80 to 95 percent of the spam
safely, and then using a new check that only seems available in
SpamAsassin 3.0 on the remainder.
The 80 percent spam blocking comes from using a combination of the
sbl-xbl.spamhaus.org, list.dsbl.org, and possibly the njabl.org and some
open relay lists.
The 95 percent comes from using a good Dynamic pool blocking list. This
has a small risk as some ISPs will renumber and move static addresses
into what they had previously told the world was a dynamic range.
The SpamAsassin 3.0 has a new check where it looks up the I.P. address
for a link in the spam. If that I.P. address shows up in the
sbl-xbl.spamhaus.org or any other open proxy list, then there is a 100%
chance of spam in the message content. But that is not enough to safely
reject it for being spam.
That score needs to be combined with the sending mail server either
being on the spam cop.net, a multi-hop list, or having a defective rDNS
to avoid blocking someone discussing spam.
And effective spam blocking means that when the mail server decides that
the mail is spam, it rejects it with a 5xx code so that if there was an
error, this gives the fastest feedback back to the sender to indicate
that there is a problem. And statistically, most of the time it
indicates a serious security breach in the sender's mail server or
system, and in an extremely small number of cases it indicates a problem
on the receiving side.
If a spam blocking service is deleting messages with out rejecting it,
then it hides it's true error rate.
Personal Opinion Only
More information about the Coco