The most likely explanation is that a spammer got his email address and
used it to spoof the From address for a large spam transmission. In
other words, it's not a bug. It's a fact of everyday Internet life. Your
son should be reminded to protect his email address vigorously and never
reveal it in any public forum.
--- REPLY SEPARATOR ---
Required only because Sue used quoted-printable format for her post.
(Really surprised an MVP would use quoted-printable in Usenet.)
To add to Sue's comment, the only reason why all these NDRs
(non-delivery reports) are getting sent back is because the receiving
mail servers are accepting the spam and then checking if the e-mail is
deliverable afterwhich they send out *new* e-mails as the NDRs. If the
receiving mail server rejected the spam DURING the mail session (by
checking if the recipient's mailbox was defined) then it would reject
non-deliverable mail at that time. Instead of accepting the spam and
then later sending back an NDR, rejecting the attempted delivery during
the mail session means the actual sending mail server gets notified of
the non-delivery. Rather than having the recieving mail server send out
an NDR, the sender gets rejected and get the NDR message put in their
own mailbox by their own sending mail host.
When a mail server accepts an e-mail and doesn't not reject it during
the mail session with the sending mail server, it has to compose a *new*
e-mail as the NDR. That means it has only the headers by which to
determine who sent that undeliverable e-mail (spam). The headers can be
forged. Anyone can put any string they want in the From, Reply-To, and
other headers which means spammers will not put in their own e-mail
address. Sending an NDR outside the mail session is just plain stupid
and shows a poor e-mail service. By rejecting the undeliverable e-mail
DURING the mail session, the receiving mail server doesn't have to send
anything to the sending mail server except the error status. The
receiver doesn't send any e-mail back to anyone. Instead the sender
gets the error status and informs whomever sent the e-mail about the
rejection. The sender knows which account tried to send the e-mail.
The receiving mail server has to guess from the headers that can be
forged.
Getting an NDR (which is a *new* mail) from the receiving mail server
shows a stupid setup. The NDR should be generated by the sending mail
server to put into the sender's mailbox. While this solves part of the
spam problem, some spammers are smart enough to use relays (i.e.,
forwarding services). A forwarding service has to first accept the
inbound e-mail and then later sends it to the receiving mail host. Even
if the receiving mail host rejects the undeliverable e-mail during the
mail session with it, the relay mail host is no longer connected to the
sending mail host. So receiving mail servers should handle e-mails
coming from relays, if at all, differently than from normal mail
servers, like requiring SPF headers so the mail server can qualify if
the sending mail host is from where the e-mail originated. From what
I've seen of SPF (
http://www.openspf.org/), it is a solution implemented
at the mail server, not at the e-mail client.
Some blacklists consider these bogus NDRs as backscatter which is
eligible for reporting in their blacklist; see
http://forum.spamcop.net/dict/Blowback.html and
http://spamlinks.net/prevent-secure-backscatter.htm. The receiving mail
server is spewing out these misdirected NDRs because they are accepting
the spam and then later sending out a *new* e-mail as the NDR rather
than rejecting the undeliverable e-mails during the mail session.
E-mail providers that don't properly reject during the mail session can
get themself blaclisted, like at SpamCop. All those misdirected NDRs
are themselves spam because the innocent recipients never solicited for
them (i.e., unsolicited NDRs = spam). The backscatter as well as the
spam is reportable to the blacklist.
