On Tue, 2004-07-20 at 16:42, Kris Deugau wrote:
>
> Er, well, sort of. It would be a DoS only if your local tools very
> carefully ignored the information provided by the MTA about the
> connecting IP on each message. For instance, I could set up my personal
> server to reject the connection if someone tries to HELO as my domain or
> my IP. I haven't felt inspired to do this, nor go any further, but it
> would be absolutely TRIVIAL for me to take note of that IP and firewall
> them- either immediately, or after some set number of tries.
>
What I was thinking was a program that simply generates a series of
packets that have the source IP address replaced with the actual target
site. Sequence the packets to approximate actual responses and I figure
most MTAs would be faked out. The system running the blacklisting
software would end up blocking a valid site.
> The same applies to any local header analysis I might do- I *KNOW* all
> the possible paths mail might take within my own systems, and I can't
> absolutely trust any headers not generated by outside systems.
>
> Presumably your MTA will be able to get the remote system's IP, and if
> that mail server has been spewing spam at you, you have good reason to
> block it. I've done this on occasion when a certain remote system was
> generating a significant volume of the unwanted mail entering my system.
>
> Most of the greylisting implementations could probably be modified to
> handle this for spam that *does* get tagged by SA; any untagged spam
> still MUST be handled manually at some stage (even if it's just moving
> the message to a shared IMAP spam folder). From there, most mail
> administrators would be able to hack up a
> Perl/shell/[scripting-language-of-choice] script to parse headers and
> block IPs.
>
Greylisting appears to work very well against spammers. In combination
with spamassassin you have as close to a 100% solution as you can get
without turning off email entirely.
> If the black hats can spoof someone else's IP coming in to your network,
> you have far bigger problems than too much incoming spam.
>
I don't think that is all that difficult if they are not trying to
actually establish a full blown connection. Pacing crafted packets
against a known MTA should actually be pretty easy.
> -kgd
--
Scot L. Harris
[EMAIL PROTECTED]
Do not count your chickens before they are hatched.
-- Aesop
