Bill Hayles wrote:
Hi, Bill,
On Sat, 09 Apr 2011 12:39:47 +0000 in message
number<[email protected]>, received here on 09/04/2011
15:38:28, W B Hacker<[email protected]> said:
Bill Hayles wrote:
Hi, fellow Bill,
Greets..
;-)
*snip*
will eventually show up.. see below in re rDNS.
OK, not strictly Exim related, but one of my hobbyhorses. If you
do that, you block a lot of legitimate servers (including
mine!).
Not so! I AM running Exim rDNS check, and did NOT block your
direct OFF tahini response.
You(r server) passed the rDNS check for the IP from whence you
connected: craybox.com .....on 80.35.22.107.
From *manual* inspection with 'host' and 'dig', one could argue
that you should NOT have passed...
Interesting, and thanks for the test. It could be said that I should
use the rDNS result as my primary_hostname, but I don't really want
to do that.
Perhaps not - but there IS a middle-ground.
A single IP is permitted PTR RR for more than one <domain>.<tld>
.... but Exim's rDNS checking is very 'wise' w/r not rejecting
unless it has to..
Fair enough. You know much more about this than me.
Don't count on THAT. Old age and 'Irish Alzheimer's here...
;-)
Also, this approach does not catch spam mail from infected
computers (of which I get plenty).
Oh, but it DOES! Near-as-dammit 100% of it.
I think you're teaching me something, and there's something I'm not
understanding. Correct me if I'm wrong.
I have a (now former) former mailing list subscriber. Let's call
them [email protected]. For the last couple of weeks, this address has
been sending me 20 or 30 spam messages per day from 65.54.190.140,
which resolves to hotmail.com. I thought that the easiest way for me
to deal with them is to reject them via a simple deny message.
*snip*
user's 'Win-desktop'.
That's what I'm dealing with here.
Those are *nearly always* on dynamic IP with no PTR RR, hence no
way to reverse that IP via a PTR RR to an A or MX record match.
Agreed, but that isn't showing up in the Exim logs. The lines are
similar to
2011-04-02 11:57:37 1Q6gXQ-0003pj-33<= [email protected]
H=(bay0-omc3-s2.bay0.hotmail.com) [65.54.190.140] P=esmtp S=6227
[email protected]
Those WILL fail Exim's rDNS check. As they should do.
But the example above won't, unless I've misunderstood something.
Not to confuse - rDNS works, BUT ... this particular example appears to
NOT be flawed server credentials, but rather an abuse OF that server BY
an attack vector of a different sort.
'Page TWO':
It appears to be a WinCrobe that has captured the login UID:PWD of a
legitimate hotmail account holder and is using hotmail as a 'smarthost'.
AND/OR
.. is surreptitiously injecting messages into the (equivalent of) the
local MUA's outbound queue, ('outbox') effectively 'piggybacking' them
onto legitimate traffic when manually sent, ELSE fired-off by a timed
cleanup runner. Or BOTH.
AND/OR
.. may NOT be the box of that list member, but rather ANOTHER member's
WinBox using their credentials but masquerading from a random walk of a
compromised auto-built address book.
ANY of those MAY get a response from the *compromised* user (who may not
be the 'apparent' sender [1]) OR from MSN Hotmail admins.
IF reported accurately and politely.
UNTIL it gets cleaned up at the source, however, rather than block all
of hotmail or even that one server in their pool, one may use a very
specific match.
If you already have such, fine.
Otherwise, the example below may be modified.
As shown, it looks for a characteristic of messages that come in via
several different compromised WinBoxen using properly-credentialed MTA,
to virtually flood Hong Kong clients - appearing to tout rental office
space, hoping that SME thru large Enterprise owners and staff (a richer
target than schoolkids) will open them:
==
defer
regex = ^Subject:: office*
log_message = DS01B office rental scam rejected
==
You can do a regex on whatever is most consistent/least likely to false.
CAVEATS:
- regex is not the cheapest of tests.
- 'warn' first, tail the logs. Then 'defer' instead of 'deny' and tail
the logs again, and often enough to back it out if it is falsing.
Bill
[1] Check the Message_ID and other MUA 'fingerprints' by grep of the
list archives. The 'apparent' perp won't respond favorably if being
framed for the infection on someone ELSE's Winbox!
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
