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 Incidents
[Top] [All Lists]

Re: Massive SPAM Increase {-2.6} {-2.6}

Subject: Re: Massive SPAM Increase {-2.6} {-2.6}
Date: Mon, 09 Oct 2006 17:33:14 -0500
--On Monday, October 09, 2006 17:29:23 -0400 Tim <tim-forensics@sentinelchicken.org> wrote:

Its purpose is to reject *all* mail from bogus MTAs - dialups,
misconifigured servers, MTAs that aren't registered in the domains' DNS
as  a "legal" MX, MTAs that don't reverse properly, etc., etc.  If the
email is  forged in any way, it will never make it to DATA.

That's great, except it makes the internet more expensive for the little guy. If you're trying to run a non-spamming personal mailserver off of a consumer DSL or cable line, you can get screwed by others' policies like this because you may not have control over your PTR records or how your ISP lists you as a non-MTA with other organizations.

Sure, argue that the little guy should just shell out for a better line,
but if he could, he wouldn't be the little guy.

It wouldn't hurt to actually read how it works before criticizing it.

Policyd-weight (the name implies what it does) provides a weighted score to each "bad" thing an MTA does. The *cumulative* score is what matters. It also *subtracts* points for good things that an MTA does. So, the situation you describe should not be a problem.

If you want to test that, send a test message to geek@stovebolt.com, and see if it gets rejected. If it does, look at the headers to see what it did.

Paul Schmehl (pauls@utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/

Attachment: p7sT2L0YPeIuj.p7s
Description: S/MIME cryptographic signature

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