Re: massive fake returned e-mail

"Sue Mosher [MVP-Outlook]" <suemvp@xxxxxxxxxxxxxxx> wrote in message news:uaAJcWVxHHA.3952@xxxxxxxxxxxxxxxxxxxxxxx
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.


.

Relevant Pages

  • Re: IIS 5s SMTP and Stopping NDRs ?
    ... If I can get the mail server to just ... kindly sending NDR reports for every email it receives that is not ... to an existing mailbox. ... the absence of any spam detection at that level. ...
    (microsoft.public.inetserver.iis.smtp_nntp)
  • Re: Return an email on outlook 2007
    ... mail server truly knows what is the real sending mail server. ... resources of your host, your sending mail host, and the receiving mail ... someone that was never involved in sending the spam. ...
    (microsoft.public.outlook.general)
  • Re: NDRs
    ... sender just flood the spam to random recipients. ... This is what is called a "Reverse NDR attack". ... If you are experiencing any of the above, chances are good your mail server ...
    (microsoft.public.windows.server.sbs)
  • Re: content filtering
    ... opinion on experience that's limited to dealing with domestic US ... Considering that the large majority of spam originates from the US, ... Now all you need is some method of identifying the sender. ... 550 code would come to the attention of the mail server admin who could ...
    (microsoft.public.exchange.admin)
  • Re: Undeliveable Mail showing up from my domain postmaster (exchan
    ... > sender just flood the spam to random recipients. ... This is what is called a "Reverse NDR attack". ... > If you are experiencing any of the above, chances are good your mail server ...
    (microsoft.public.windows.server.sbs)
Loading