I have two mail servers. The primary is here in our office, the
secondary in our NC just in case our primary pipe goes down. The
thing is, even if the primary is up and working, the secondary server
gets an awful lot of mail -- nearly all of it spam as best I can tell.
Most of it, if it's to an existing user, is accepted because we don't
have any anti-spam stuff installed yet, but it's the following log
entries that have me concerned.
Below you'll find what appears to be an attempt by someone in russia
pretending to be from someone else in russia sending stuff to users
that don't exist in our system. The secondary server appears to be
bouncing these mails back to the fake sender -- obviously something
Bad, but I'm not sure how to stop it as it all looks legit.
Suggestions?
# grep 1FdnXi-0006bg-Jb mainlog
2006-05-10 12:11:51 1FdnXi-0006bg-Jb <= tfuz (AT) rbc (DOT) ru
[82.58.102.79] P=smtp S=25748
id=036b01c6741a$a43423d0$aa2ded53@valeriy
2006-05-10 12:11:52 1FdnXi-0006bg-Jb ** mail (AT) MYDMAIN (DOT) com R=dnslookup
T=remote_smtp: SMTP error from remote mail server after RCPT
T:<mail (AT) MYDMAIN (DOT) com>: host cohen.MYDMAIN.com [MX0-IP]: 550 unknown
user
2006-05-10 12:11:52 1FdnXi-0006bg-Jb ** MYDMAIN (AT) MYDMAIN (DOT) com
R=dnslookup T=remote_smtp: SMTP error from remote mail server after
RCPT T:<MYDMAIN (AT) MYDMAIN (DOT) com>: host cohen.MYDMAIN.com [MX0-IP]: 550
unknown user
2006-05-10 12:11:52 1FdnXi-0006bg-Jb ** admin (AT) MYDMAIN (DOT) com R=dnslookup
T=remote_smtp: SMTP error from remote mail server after RCPT
T:<admin (AT) MYDMAIN (DOT) com>: host cohen.MYDMAIN.com [MX0-IP]: 550 unknown
user
2006-05-10 12:11:52 1FdnXi-0006bg-Jb ** info (AT) MYDMAIN (DOT) com R=dnslookup
T=remote_smtp: SMTP error from remote mail server after RCPT
T:<info (AT) MYDMAIN (DOT) com>: host cohen.MYDMAIN.com [MX0-IP]: 550 unknown
user
2006-05-10 12:11:52 1FdnXk-0006bo-87 <= <R=1FdnXi-0006bg-Jb U=mailnull
P=local S=27199
2006-05-10 12:11:52 1FdnXi-0006bg-Jb Completed
# grep 1FdnXk-0006bo-87 mainlog
2006-05-10 12:11:52 1FdnXk-0006bo-87 <= <R=1FdnXi-0006bg-Jb U=mailnull
P=local S=27199
2006-05-10 12:11:55 1FdnXk-0006bo-87 ** tfuz (AT) rbc (DOT) ru R=dnslookup
T=remote_smtp: SMTP error from remote mail server after RCPT
T:<tfuz (AT) rbc (DOT) ru>: host smtp.rbc.ru [80.68.240.83]: 550 <tfuz (AT) rbc (DOT) ru>:
User unknown in relay recipient table
2006-05-10 12:11:55 1FdnXk-0006bo-87 Frozen (delivery error message)
2006-05-10 12:28:42 1FdnXk-0006bo-87 Message is frozen
2006-05-10 12:58:42 1FdnXk-0006bo-87 Message is frozen
2006-05-10 13:29:58 1FdnXk-0006bo-87 Message is frozen

Daniel wrote:
I have two mail servers. The primary is here in our office, the
secondary in our NC just in case our primary pipe goes down. The
thing is, even if the primary is up and working, the secondary server
gets an awful lot of mail -- nearly all of it spam as best I can tell.
Most of it, if it's to an existing user, is accepted because we don't
have any anti-spam stuff installed yet, but it's the following log
entries that have me concerned.

Below you'll find what appears to be an attempt by someone in russia
pretending to be from someone else in russia sending stuff to users
that don't exist in our system. The secondary server appears to be
bouncing these mails back to the fake sender -- obviously something
Bad, but I'm not sure how to stop it as it all looks legit.
Suggestions?
--

You need spam filtering on the backup server as well. There are a number
of tricks you can do to reduce spam on the backups. A lot of spammers go
for the highest MX first because the backup servers often don't have
spam filtering.

I have 3 layers of MX records. My highest one always returns DEFER just
to keep me from having to process the spam. That in itself will cut your
spam quite a bit, Also use the various block lists like spamhaus.

Anyhow - one of my tricks. Create a third MX that is higher than the
other two. Then add this ACL

defer log_message = Spammer Connected to FAKE highest MX record
condition = ${if
match{$interface_address}{69.50.231.7}{true}{false }}

then add this:

# Look up in a few choice primary blacklists. Must be after
authenticated tests.

drop message = REJECTED - ${sender_host_address} is blacklisted at
$dnslist_domain ($dnslist_value); \
See ${dnslist_text}
dnslists =
sbl-xbl.spamhaus.org/<;$sender_host_address;$sender_address_domain

Wednesday 10 May 2006 19:23 skrev Daniel:
I have two mail servers. The primary is here in our office, the
secondary in our NC just in case our primary pipe goes down. The
thing is, even if the primary is up and working, the secondary server
gets an awful lot of mail -- nearly all of it spam as best I can tell.
Most of it, if it's to an existing user, is accepted because we don't
have any anti-spam stuff installed yet, but it's the following log
entries that have me concerned.

Below you'll find what appears to be an attempt by someone in russia
pretending to be from someone else in russia sending stuff to users
that don't exist in our system. The secondary server appears to be
bouncing these mails back to the fake sender -- obviously something
Bad, but I'm not sure how to stop it as it all looks legit.
Suggestions?

Spammers routinely target secondary mail exchangers for precisely this
reason - often the secondaries have worse or no spam protection or will
accept anything dropped on them and then bounce undeliverable mail to the
purported sender.

You really should perform at least some basic checks before accepting:

* Suspect HEL greetings ("localhost", "friend", the name of your server,
etc.):

deny condition = ${if match {${lc:$sender_helo_name}} \
{^(friend|localhost|$primary_hostname|$interface_a ddress)\$}}

* Some good DNSBLs:

deny message = Client host [$sender_host_address] is listed in \
$dnslist_domain ($dnslist_text)
dnslists = list.dsbl.org : sbl-xbl.spamhaus.org : dnsbl.njabl.org

* Check that at least the sender domain exists:
require verify = sender/defer_ok

Then do callouts to verify the recipient:

require verify = recipient/callout=10s,defer_ok

defer_ok ensures that mail will be accepted when the primary really *is* down.

You can probably figure out where and in which order to place these statements
yourself.

Marc Perkel wrote:
Anyhow - one of my tricks. Create a third MX that is higher than the
other two. Then add this ACL

defer log_message = Spammer Connected to FAKE highest MX record
condition = ${if
match{$interface_address}{69.50.231.7}{true}{false }}

Not wishing to be pedantic, but it's not a fake record, it's a real
one. Also it's perfectly possible that it's not a spammer, but a host
that is having trouble reaching your primary MX. You logic assumes that
a spammer will always and only try the lowest priority MX record, that's
unlikely to be universally correct.

Regards

Martin A. Brooks wrote:
Marc Perkel wrote:
>Anyhow - one of my tricks. Create a third MX that is higher than the
>other two. Then add this ACL
>>
>defer log_message = Spammer Connected to FAKE highest MX record
>condition = ${if
>match{$interface_address}{69.50.231.7}{true}{false }}
>
Not wishing to be pedantic, but it's not a fake record, it's a real
one. Also it's perfectly possible that it's not a spammer, but a host
that is having trouble reaching your primary MX. You logic assumes that
a spammer will always and only try the lowest priority MX record, that's
unlikely to be universally correct.

Regards

What I do is create a fake highest MX and then defer everything that
hits it. I get rid of about 120,000 spam attempts a day using it.

Wed, 10 May 2006, Martin A. Brooks wrote:

Marc Perkel wrote:
Anyhow - one of my tricks. Create a third MX that is higher than the
other two.

This was certainly a possibility that we had considered in the past,
having observed the apparent propensity of some spammers to go for
higher-numbered MXes without showing any signs of having tried the
first-choice MX first, even when we knew it was fully working.

Then add this ACL
[snip hopelessly over-agressive code]

However, it seemed to us that one should take great care about what
action one takes in response.

Not wishing to be pedantic, but it's not a fake record, it's a real
one.

Agreed

Also it's perfectly possible that it's not a spammer, but a host
that is having trouble reaching your primary MX.

It's conceivable - even though it should be rather rare.

You logic assumes that a spammer will always and only try the lowest
priority MX record,

By no means! It's based on an observation that enough of them do so
that it's been noticed quite widely. But it certainly would not
replace existing defences.

I know that some commentators have guessed that spammers were doing
their DNS lookups casually, and picking arbitrary MX hosts,[1]
irrespective of the associated priority. I have to say that my hunch
is that some, at least, are quite deliberately going for the backup
host, hoping that it will be less well protected against abuse.

I'd be inclined to respond on that "third" (of "fake") MX with a
defer. Bona fide senders would surely try the preferred MX, sooner or
later, wouldn't they? Spammers, on the whole, can't be bothered with
organised retries. Indeed, with any luck, such retries might have
similar effect to greylisting, and, by the time that they finally got
to trying the first or second MX, they'd already have got into dnsBLs,
and could be rejected by the other defences.

However, this is only an idea that we discussed - we never did get to
try it, so I can't offer any reports on how it works out in practice,
sorry.

[1] Incidentally, we had some clear evidence that spammers keep old
lists of MX lookups, instead of looking-up in real time - so it could
be beneficial to regularly change one's MX IPs, and letting them try
to offer the mail to last month's IP which has now gone away ;-)

Magnus Holmgren wrote:

require verify = recipient/callout=10s,defer_ok

defer_ok ensures that mail will be accepted when the primary really *is* down.

The section in the docs on 'Callout verification' says:

"Note that for a sender address, the
callback is not to the client host that is trying to deliver the
message, but to one of the hosts that accepts incoming mail for the
sender's domain.
[]
For a sender callout check, Exim makes SMTP connections to the
remote hosts, to test whether a bounce message could be delivered to
the sender address. The following SMTP commands are sent:
[]
If the response to the RCPT command is a 2_xx_ code, the verification
succeeds. If it is 5_xx_, the verification fails. For any other
condition, Exim tries the next host, if any. If there is a problem with
all the remote hosts, the ACL yields "defer", unless the `defer_ok'
parameter of the `callout' option is given, in which case the condition
is forced to succeed."

Considering that, what's the actual benefit of using the defer_ok option?

If a SPAMer has set up MXs that point to non-accepting hosts, he will
get the SPAM through because you set defer_ok.

GH

Thursday 11 May 2006 14:57 skrev listrcv:
Magnus Holmgren wrote:
require verify = recipient/callout=10s,defer_ok

defer_ok ensures that mail will be accepted when the primary really *is*
down.

The section in the docs on 'Callout verification' says:

"Note that for a sender address, the
callback is not to the client host that is trying to deliver the
message, but to one of the hosts that accepts incoming mail for the
sender's domain.
[]
For a sender callout check, Exim makes SMTP connections to the
remote hosts, to test whether a bounce message could be delivered to
the sender address. The following SMTP commands are sent:
[]
If the response to the RCPT command is a 2_xx_ code, the verification
succeeds. If it is 5_xx_, the verification fails. For any other
condition, Exim tries the next host, if any. If there is a problem with
all the remote hosts, the ACL yields "defer", unless the `defer_ok'
parameter of the `callout' option is given, in which case the condition
is forced to succeed."

Considering that, what's the actual benefit of using the defer_ok option?

Now you're quoting two sections relating to sender (callback) checks, but from
my mail you quote the recipient (call-forward) check. I'm confused, but I'll
cover both ways.

Using a call-forward without defer_ok would render the secondary effectively
meaningless (except in the rare cases where a sending MTA can reach the
secondary but not the primary for some reason, even though the latter is up).
If the primary MX is down, the callout will return defer, and the sending MTA
will have to retain the mail. The secondary's job is (normally) to accept
mail when the primary is down. In the other hand, when the primary is up,
there's really no reason to contact the secondary, but if anyone does, we ask
the primary whether the recipient exists.

If a SPAMer has set up MXs that point to non-accepting hosts, he will
get the SPAM through because you set defer_ok.

The reasoning behind defer_ok on the sender verification is that it might
cause too many false positives. That could be wrong, YMMV, try for yourself.
Anyway, if the spammer bothers to set up a sender address that causes
verification to defer, they could as easily set up a sender address that
verifies K.

Marc Perkel wrote:
Anyhow - one of my tricks. Create a third MX that is higher than the
other two. Then add this ACL

defer log_message = Spammer Connected to FAKE highest MX record
condition = ${if
match{$interface_address}{69.50.231.7}{true}{false }}

Not wishing to be pedantic, but it's not a fake record, it's a real
one. Also it's perfectly possible that it's not a spammer, but a host
that is having trouble reaching your primary MX. You logic assumes that
a spammer will always and only try the lowest priority MX record, that's
unlikely to be universally correct.

Regards

"Alan J. Flavell" <a.flavell (AT) physics (DOT) gla.ac.uksaid, in message
@ppepc20.ph.gla.ac.uk:

[1] Incidentally, we had some clear evidence that spammers keep old
lists of MX lookups, instead of looking-up in real time - so it could
be beneficial to regularly change one's MX IPs, and letting them try
to offer the mail to last month's IP which has now gone away ;-)

I've been meaning to do something like this for a while. The corollory
would be, after moving the IP, to firewall the old IP and watch the
firewall logs. Anyone hitting the old IP (after some reasonable grace
period) on port 25 is pretty much bound to be a spammer/zombie and
can be added to a local blacklist.

of interest, I knocked together that part of the code yesterday
morning. It actually looks for ALL blocked port 25 probes against
our site. The blacklist now holds 308 IP addresses that have tried to
talk to our old MX IP's. The old IPs were removed from our MX record
in September 2003!

Another interesting finding is that 462 IP addresses have tried to
talk to machines which are listed in the A record for aber.ac.uk.
These have also been added to the blacklist, but I can't decide
whether that's a good thing to do (is there ANY legitimate reason
to hit the A record rather than the MX record?!).

The blocklist now contains 1911 records, gathered in 23 hours. It's
tempting to make it into some form of DNSBL actually

Cheers,
Alun.

p.s. Make that 1915 entries - 4 more appeared while I was proofreading this!

Wed, 10 May 2006, Martin A. Brooks wrote:

Not wishing to be pedantic, but it's not a fake record, it's a real
one. Also it's perfectly possible that it's not a spammer, but a host
that is having trouble reaching your primary MX.

The way some people do this is to have the "fake real" MX point to a
second IP address on the same host as the primary MX. Therefore, the
chance of a real MTA accessing the fake when it can't access the primary
is very small.

Fri, 12 May 2006, Alun wrote:

"Alan J. Flavell" <a.flavell (AT) physics (DOT) gla.ac.uksaid, in message
@ppepc20.ph.gla.ac.uk:

[1] Incidentally, we had some clear evidence that spammers keep
old lists of MX lookups, instead of looking-up in real time - so
it could be beneficial to regularly change one's MX IPs, and
letting them try to offer the mail to last month's IP which has
now gone away ;-)

I've been meaning to do something like this for a while. The
corollory would be, after moving the IP, to firewall the old IP and
watch the firewall logs.

K, I wasn't sure if my throwaway remark above would raise any
interest, but, as it has (thanks for reporting the results of your
experiment!), maybe I could add just a bit of detail.

There are two particular scenarios which I have seen. I'll use
obfuscated names, since the details of the real ones aren't of any
significance here.

1. old host-based addresses

In ancient history, we recognised host-based address domains
like host5.dom.example

Then, in less-ancient history we moved their mail service to a
collective mail server by means of MX records, with host5.dom.example
pointing to mail.domain.example

(These were not only different domains, but even different IP
network numbers.)

course, in the fullness of time, we removed the MX records for
those old hosts, and reconfigured the mailer to reject the old
addresses.

Nevertheless, spammers were continuing to offer to our mailer,
mail intended for the old host-based domains.

The only possible hypothesis must be that they were using obsolete MX
records which had been harvested long ago.

2. New mail server

Fairly recently, a new mail server was worked-up, let's call it
newmail.domain.example, and the MX records for our currently-supported
mail domains were pointed to it. In due course, after a bit of
parallel working, the old MX records pointing to the old server
mail.domain.example were removed.

After a while, the old mailer mail.domain.example was firewalled.
Nevertheless, weeks afterwards, SMTP transactions were still being
attempted to it.

So, that's one example of long-term stale MX records, and another
example of relatively short-term - but still inappropriate - stale MX
records.

I can't say anything really about spammers attempting A records for
hosts, because our campus border router blocks incoming port 25 for
anything which isn't registered as a bona fide mail server. So we'd
never get to see the spammers attempting SMTP transactions to our
other hosts.

I *suppose* the campus network folks could organise some kind of
blacklisting based on firewall logs, but that's way outside of my own
orbit, so I'll leave that to Chris and f(r)iends ;-)

Hope that's vaguely useful.

"Alan J. Flavell" <a.flavell (AT) physics (DOT) gla.ac.uksaid, in message
@ppepc87.ph.gla.ac.uk:

I've been meaning to do something like this for a while. The
corollory would be, after moving the IP, to firewall the old IP and
watch the firewall logs.

K, I wasn't sure if my throwaway remark above would raise any
interest, but, as it has (thanks for reporting the results of your
experiment!), maybe I could add just a bit of detail.

It's interesting just how crazy some of this spamware is! I wonder what
percentage of the world's MX records (when resolved down to the IP address
level) have stayed the same over the course of 2.5 years (which is the highest
figure I can prove from my logs).

I've spotted one possible problem with this approach here. Someone who
controls the DNS for a domain could register an MX record pointing to
a machine on our network. If they then mail an address at that domain
from e.g. hotmail, hotmail will attempt to connect to it and the firewall
will log it, leading to the blacklisting of one of hotmail's outbound
servers. I've discovered this because someone appears to have done just
that (well, they've hit messagelabs, but still)!

Cheers,
Alun.

p.s. 2007 hosts and counting.

12 May 2006 09:29:18 +0100 Alun <auj (AT) aber (DOT) ac.ukwrote:

"Alan J. Flavell" <a.flavell (AT) physics (DOT) gla.ac.uksaid, in message
@ppepc20.ph.gla.ac.uk:
>>
>[1] Incidentally, we had some clear evidence that spammers keep old
>lists of MX lookups, instead of looking-up in real time - so it could
>be beneficial to regularly change one's MX IPs, and letting them try
>to offer the mail to last month's IP which has now gone away ;-)
>
I've been meaning to do something like this for a while. The corollory
would be, after moving the IP, to firewall the old IP and watch the
firewall logs. Anyone hitting the old IP (after some reasonable grace
period)

Is that grace period different from the DNS TTL?

on port 25 is pretty much bound to be a spammer/zombie and
can be added to a local blacklist.

of interest, I knocked together that part of the code yesterday
morning. It actually looks for ALL blocked port 25 probes against
our site. The blacklist now holds 308 IP addresses that have tried to
talk to our old MX IP's. The old IPs were removed from our MX record
in September 2003!

Another interesting finding is that 462 IP addresses have tried to
talk to machines which are listed in the A record for aber.ac.uk.
These have also been added to the blacklist, but I can't decide
whether that's a good thing to do (is there ANY legitimate reason
to hit the A record rather than the MX record?!).

The blocklist now contains 1911 records, gathered in 23 hours. It's
tempting to make it into some form of DNSBL actually

Cheers,
Alun.

p.s. Make that 1915 entries - 4 more appeared while I was proofreading
this! --
Alun Jones auj (AT) aber (DOT) as.c.uk
Systems Support, (01970) 62 2494
Information Services,
University of Wales, Aberystwyth

Magnus Holmgren wrote:

>>Considering that, what's the actual benefit of using the defer_ok option?

Now you're quoting two sections relating to sender (callback) checks, but from
my mail you quote the recipient (call-forward) check. I'm confused, but I'll
cover both ways.

, sorry, it's me who confused that. I thought it was sender verification.

Using a call-forward without defer_ok would render the secondary effectively
meaningless

That's true, very good explanation, thanks!

>>If a SPAMer has set up MXs that point to non-accepting hosts, he will
>>get the SPAM through because you set defer_ok.

The reasoning behind defer_ok on the sender verification is that it might
cause too many false positives. That could be wrong, YMMV, try for yourself.

I have enabled sender verification callouts, but without defer_ok. The
idea that it might be a good idea to enable defer_ok is what made me ask.

But when I rethink that The callout sender verification does two
things, ensuring the sending address is reachable and, in a side effect,
wards off _lots_ of SPAM.

Denying mail from unreachable addresses is mandatory because once you
accept a mail, you are responsible for handling it according to the
standards which includes eventually sending delivery errors. Since
you cannot send anything to unreachable addresses, accepting mail from
them is a violation of RFCs letting aside that I don't want a
mailserver to be that unreliable.

Setting defer_ok would lead to accept all the SPAM and mail from
unreachable addresses. Not a good idea

Anyway, if the spammer bothers to set up a sender address that causes
verification to defer, they could as easily set up a sender address that
verifies K.

Yeah, fortunately most of them don't do that. What gets through and is
detected as SPAM here is a little less than 1.3 mails per day per user.
Taking undetected SPAM into accout, it's maybe 1.5 a bearable rate.

Thus, I don't understand why so many mail service providers are so
exited about SPAM that many of them misconfigure their servers to use
sucking blacklists. But then, most of them don't know what they do, anyway.

GH

Ian Eiloart <iane (AT) sussex (DOT) ac.uksaid, in message
D01A5F8DE52A40AABB0645C1 (AT) lewes (DOT) staff.uscs.susx.ac.uk:

I've been meaning to do something like this for a while. The
corollory would be, after moving the IP, to firewall the old IP and
watch the firewall logs. Anyone hitting the old IP (after some
reasonable grace period)

Is that grace period different from the DNS TTL?

Probably not, but I think I'd give it the DNS TTL plus some value, just to
be sure.

I've been looking at what's been blocked. I take away the 90% that
are obviously home connections or which don't have reverse lookups, I'm
left with some very strange results. For example, the following have
all attempted to connect to A records for aber.ac.uk:

- port 25 has Microsoft ESMTP MAIL Service Version: 5.0.2195.6713
hasn't connected to any of our inbound servers

mail-kr.bigfoot.com
- LiteMail v3.03
has connected to our inbound servers too

mail-relay8.elsevier.co.uk
- MAILsweeper ESMTP Receiver Version 4.3.17.0
has connected to out inbound servers too

mail.sihe.ac.uk
- Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830
has connected to out inbound servers too

It's fairly obvious that these are genuine outbound mail servers, but I'm
very confused as to why doing it. We use greylisting, so for the latter
three I guess it could be that they've tried the MX record, hit our
greylisting and are now failing back to the A record. Would this be
valid behaviour?

Cheers,
Alun.

Alun <auj (AT) aber (DOT) ac.uksaid, in message
20060512135215.1b7da9ca (AT) pcebbj (DOT) ccu.aber.ac.uk:

It's fairly obvious that these are genuine outbound mail servers, but
I'm very confused as to why doing it. We use greylisting, so for the
latter three I guess it could be that they've tried the MX record,
hit our greylisting and are now failing back to the A record. Would
this be valid behaviour?

Should have looked at the RFC before asking that question:

5. Address Resolution and Mail Handling

[]

The lookup first attempts to locate an MX record associated with the
name. If a CNAME record is found instead, the resulting name is
processed as if it were the initial name. If no MX records are found,
but an A RR is found, the A RR is treated as if it was associated with an
implicit MX RR, with a preference of 0, pointing to that host. If one or
more MX RRs are found for a given name, SMTP systems MUST NT utilize any
A RRs associated with that name unless they are located using the MX RRs;
the "implicit MX" rule above applies only if there are no MX records
present. If MX records are present, but none of them are usable, this
situation MUST be reported as an error.

I read that as meaning that it's not correct behaviour to fall back to the A
record when the machines identified by the MX record defer.

Cheers,
Alun.