On 12/17/2010 10:15 AM, Kris Deugau wrote:
Ted Mittelstaedt wrote:
I know that, Sendmail adds the same flag when setup for auth SMTP. The
problem is that SA will see this and assume the mail is safe.
Noooo.... if your trust path is set correctly, then SA won't run tests
like eg PBL (IP blocks designated by the nominal owner as "not allowed
to send SMTP traffic to world+dog"). It does NOT mean SA treats the mail
as "safe".
That doesn't help us you see because we have users who send mail that
is constructed in such a way as it will trigger the other SA tests,
yet they insist on being allowed to send it.
In the versions of SA I have used, SA will assume the mail is safe
no matter what Received line in the header has the auth indicator
set. They may have fixed that in the most recent SA but I don't
believe so,
*scratch head* I've never had problems with mistaken RBL hits
It's not the RBL hits that are the problem.
as the OP
is asking about *if* I've got my *_networks set correctly. Earlier this
year I discovered an edge case with our "accelerated dialup" service and
had to make some adjustments to the trust path to include the
accelerator host as an MSA - but previous to that the setup had been
working correctly.
and even if they did then what if SA is running on a
prefilter server in front of an Exchange server for example?
I have no idea what scenario you're referring to here - inbound mail?
The OP is asking about outbound mail; and so far as your own filtering
is concerned, (especially) if you're an ISP your spam filter really
shouldn't penalize customers who send mail directly through the SMTP
server you provide, whether that's separate from your MX(es) or not.
Exactly my point. The problem I have had with SA as I said in my
original response is that even if you use authenticated SMTP that
setting the auth flag in the received header simply didn't work.
Even when it is there, SA still filtered. If you say that setting
the flag only makes SA skip the RBL checks then I believe you,
but what is the point, the RBL checks aren't the issue. The
filtering is the issue.
It is possible this is because I use sa-milter. It is possible
this is because I have an older SA version that's been fixed now.
There's many possibilities. But, whatever the problem, the
easy fix was using a separate machine for auth-smtp and not
running SA on it. It was
only a few years later after doing this when I stated seeing the
spammers cracking auth-smtp passwords, that I realized how many
OTHER benefits to using a separate auth-smtp server that there are.
And you still have the problem of if a spammer's custom-written
virus has determined a user password. The spammers are now able
to do this with some of their hijack tools. And there are also a
LOT of phishing spams now that we see from time to time that tell
users that their e-mail password needs to be reset and to go to
such and such a webpage and change it, etc.
I'm not sure where you're going with this, but this scenario will be a
problem with SMTP AUTH no matter how that info is passed to SA. Unless
you can guarantee real control over end-user systems, you *will* have to
deal with this somehow. I'll leave it at that since the original
question was about preventing PBL hits on authenticated users.
And my original answer was don't run SA on the authenticated users
by the solution of using a separate auth-smtp machine.
But, go ahead, do it your way. If your a small site you might
even be OK for long enough to forget this advice. But sooner
or later your going to get cracked into and you will wish you
had separated the servers.
The ISP I work for currently has 6 machines handling customer-facing
mail services - two physical machines for MX, two for outbound SMTP and
two running SA and Clam.
I've worked with a number of single-machine and partial-split
configurations on a smaller scale, but I don't recall any special
challenges tracking down a cracked account. TBH the only "problem" I
recall was the size of the logfiles relative to available CPU power to
search them.
Dealing with the logfiles is an issue but more of an issue is when
the spammers are using a hijacked system that isn't on a very fast
line or isn't sending traffic very fast. In those cases one of
my tricks is to temporarily change the server to queueing-only,
then let the server alone for 20 minutes. Then it is really easy
to identify the spam in the mail queue because there is so much
of it relative to the legitimate mail.
Spammers have gotten very tricky and nowadays they parallelize spamruns.
What they will do is your compromised machine will not just have a
single message that it hammers out to 10,000 victims, instead it has
100 different messages that are hammered out to 100 different victims.
Presumably they have 100 other machines across the Internet that are
also cracked and are doing the same thing that are working on alternate
chunks of the victim list.
When I have to track these things now I am increasingly finding
the queue filled up with 5-10 groups of spams that are entirely
different messages. I might have 1000 messages in there but only
100 of them have the same payload. (of course, each group is a
variation on the same theme) It makes it harder to find
the commonality. Of course, once you find the commonality then
it is a simple matter to identify the sending IP address, and then
use your other logs to see what userID authenticated in with that
address. The spammers are doing this because it reduces commonality
in the mail log, and makes it a lot harder to isolate the sending
IP address.
Another thing they do is they used to throw 30-40 senders at you,
all using the same compromised credential. But now it's usually less
than 10. I had one 3 weeks ago that used a total of 6 senders.
The spammers are probably doing that because they find when they
use lots of machines that the admin of the relay host reports all
their machines and then the spammers suddenly lose a good chunk of
their DDoS network. By reducing the number of transmitters on each
mule, it limits the liability should they happen to use a mule
with a clueful sysadmin.
Ted
-kgd
