Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Security-Basics
[Top] [All Lists]

Re: New Spam Delivery Technique

Subject: Re: New Spam Delivery Technique
Date: Sat, 21 Jul 2007 15:24:02 +0200
On 2007-07-20 tony barry wrote:
I think I didn't explain clearly first time. Its not the PDF attachment
thats new its the delivery method.

The spammer forges the sender address to anyone@mydomain.com and sends
it to doesnotexist@ligitimatecompany.com.

That also isn't new, but indeed seems to be exploited more and more.

Ligitimate companys mailer receives the message finds the recipient is
not on its list, crafts a 'Could not deliver mail' message, Attaches the
spammers original message and sends it to anyone@mydomain.com where my
catch all account receives it because the spam filter does not reject
Mailer Daemons failed to deliver mail messages 'cause I want to know
that.

That's how SMTP is supposed to work: once a server accepts mail for
relaying and later finds he's not able to deliver it he is supposed to
send an NDR to the recipient given in the Return-Path. However, since
Spammers forge these addresses, it's become a bad practice to accept
first and bounce later. What mail server admins *should* do is check the
mail in the SMTP dialog and reject it if they can't deliver it (e.g.
because the recipient doesn't exist. That way the bounce will not go to
the (forged) Return-Path, but back to the sending MTA.

While typing this a thought has occurred to me. What would happen if I
did not have a catch all account and my mail server also rejected the
message. Would it be bounced back to Ligitimatecompany.com or to
mydomain.com?

Well, first of all: you do not want to have a catch-all in the first
place. Aside from that: if your MTA rejects the mail in the SMTP dialog
(as it should), the bounce won't go to either Ligitimatecompany.com or
mydomain.com, but back to the sending MTA.

How long would this message bounce around the internet looking for a
home.

That depends on how either MTA will handle it, but since virtually every
MTA does loop-detection nowadays: not very long. However, it still is a
REALLY BAD idea to accept first and bounce later.

Second thought. If ligitimatecompany.com (and others) is/are receiving
messages supposedly from mydomain.com (or yourdomain.com) that have a
high spam score what is the likely hood of mydomain.com ending up on a
spammers blacklist.

If smart people are dealing with it: void. If stupid people are dealing
with it: well, all bets are off then.

Regards
Ansgar Wiechers
-- 
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

<Prev in Thread] Current Thread [Next in Thread>