On Tue, Jun 15, 2004 at 11:24:12AM -0500, Bob Apthorpe wrote: > > Because they are bounce (non-delivery notification) messages from a remote > system, not traditional direct spam. This is what's known as backscatter > or 'bounce spam' - the condition when error messages are sent to an > unrelated third party (you) due to misconfiguration or an obsolete mail > architecture, e.g. one which blindly accepts messages and propogates error > messages to an unverified envelope sender (or worse, to the sender in the > From: header) rather than performing the checks during the SMTP > transaction and returning an error code the the actual delivering system. > > > >Reporting-MTA: dns; mta5-win.server.ntlworld.com > > >Arrival-Date: Tue, 15 Jun 2004 15:34:39 +0100 > > >Received-From-MTA: dns; d57-77-98.home.cgocable.net (24.57.77.98) > > ... from d57-77-98.home.cgocable.net (24.57.77.98) which is most probably > an exploited Wintel box on an unfirewalled cable modem.
Ahh, I begin to understand why my spamassassin config can't sort this out the way I have it set up. > Yup - a check of > 24.57.77.98 against openrbl.org shows that address blacklisted to hell and > back as an open proxy. > > So there you have it - ntlworld.net's mail servers will accept obviously > junk connections from any old dynamically-allocated IP address, sit on a > piece of spam until they figure out it's undeliverable, then bounce it to > some random victim totally unrelated to the actual sender. Under spamassassin 2.63 is ther a way to catch these? A pointer at what part of the docs to read would be very helpful. Do I need to set up and configure rbl's? I haven't because of (my percieved, not necessarily real) concept of major performance hits when using these. Are they something to do with the "network checks" I vaguely recall disabling on purpose? Lastly, should I just wait until 3.x is out, to avoid having to learn it all again shortly? thanks, -chuck
