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: ***SPAM*** Re: Massive SPAM Increase {-2.6} {-2.6}

Subject: Re: ***SPAM*** Re: Massive SPAM Increase {-2.6} {-2.6}
Date: Sat, 14 Oct 2006 01:44:04 -0400
On Fri, 13 Oct 2006 22:52:12 CDT, you said:

I'm not sure what you mean by "split inbound and outbound", but any
outbound MX host *should* be listed in DNS.

Tell you what.  Explain what an *OUTBOUND* MX is, and I'll see what I can do.

The machine in question is *NOT* listed as an MX, because it is *NOT* a
machine that should be accepting *inbound* mail for the domain.  Its purpose
in life is to send mail to off-campus sites.

But then, utdallas.edu can't pass that check either - I'm checking back
through the various mail you've sent, and I found this header:

Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12])  by lists
.grok.org.uk (Postfix) with ESMTP id EA6DD608   for  <full-disclosure@lists.grok
.org.uk>; Thu, 12 Oct 2006 16:54:20 +0100 (BST)

However, the DNS says:

utdallas.edu.           46676   IN      MX      10 mx2.utdallas.edu.
utdallas.edu.           46676   IN      MX      20 mx0.utdallas.edu.
mx2.utdallas.edu.       76415   IN      A       129.110.10.17
mx0.utdallas.edu.       46676   IN      A       129.110.10.17

At least SPF, for all it's busticatedness, understood that at many sites,
the MX is *not* the outbound box (and in fact, the asymmetric configuration
is why you need an SPF record rather than testing the MX values...)

Attachment: pgpYJ6IRn6mqh.pgp
Description: PGP signature

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