login
Search
Hi all,
At around 1:40 PM (PDT) my SMTP server started getting flooded
by enormous amount of connections. The connections were for
seemingly random "users" @my-domain-name.I'm running spamdb in greylist mode, but these servers were
getting white-listed very quickly.$ /usr/sbin/spamdb | /usr/bin/grep -c ^WHITE
717Typical value for above is not more than 20. Traffic going
in/out of my mail-server is minimal.I would remove them from the WHITE list and they would fill up
almost immediately.My guess is someone is using these faked addresses (user@my-domain)
to send out SPAM and I'm getting the bounces from these.I'm basically looking for opinions as how to combat this problem
right now. I'm not even 100% on the bounced email theory, but
this had happened to me once before back in May 2003, but the
bounces were mainly from gc.ca domain.I use gmane to read the list. If not too much to ask, please CC
me on your reply(ies).Thanks,
--patrickp.s., Server is running cvs updated -rOPENBSD_4_1 code.
Then it sounds almost like you were running with a too short passtime,
We've been seeing a lot of that here, too. Mostly it's a few (maybe
20) a day to the most widely known domain here, then occasionally
somebody pushes the "generate" button for too long and one domain
almost nobody actually uses gets the bouces for 700+ fake
addresses[1]. Bob Beck's greyscanner is rather effective, as is the
more manual methods I've blogged about the observations quite a bit,
starting with [2].Short summary for those who are not too interested in blog posts: I
started seeing more than the usual amount of bounce activity in my
mail server log summaries, close enough to what you describe. So
after a bit of thinking and log browsing I decided this was generated
mainly by misconfigured mail servers bouncing spam. Then I decided I
wanted to do an experiment, to see if I could poison the well and at
the same time get a feel for the data I was collecting.I started publishing the fake addresses on a web page[3] as well as
entering them into the list of trap addresses. I've been seeing
evidence that the addresses are actually being harvested and used as
to-be-spammed addresses too: addresses which are all uppercase on the
web page turning up in the spamd logs and greylist dumps in all
lowercase, addresses which have been on my flypaper list for months
turn up all the time, and we see a steadily growing number of hosts in
TRAPPED state.My users here are not getting any more spam than they used to (as
close as does not matter to none), false positives are pretty much an
unknown, and it looks like we're succeeding in making the spammers
work harder.[1] http://bsdly.blogspot.com/2007/08/lady-in-distress-or-then-again-maybe.html
[2] http://bsdly.blogspot.com/2007/07/hey-spammer-heres-list-for-you.html
[3] http://www.bsdly.net/~peter/traplist.html--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ [ message continues ]
I have just re-opened my SMTP port which I had shut since 1440
Sunday. Not 1 hour has passed yet and my GREY list is almost
at 300.I've added about 250 (count at the time) bogus emails to the
greytrap list but since they are unique I don't think it will
help the situation much.I'm very certain right now, this flood is due to a spammer
using these fake addresses @my-domain-name to spam these mail
server (all around the world -- Japan, South America, US,
Germany, Ireland, etc...) and I'm getting the brunt of it in
the form of these bounced messages.At this point I think I have no other choice but to wait out
When you speak of "misconfigured mail servers bouncing spam",
what exactly is a "proper configured mail server" supposed to
do with spam directed at non-existing user @their-host-name?Just curious.
FYI, as of now my:
- GREY list count is 342 (and growing)
- unique bogus email count is 341
- ESTABLISHED spamd connection count is 63 (and growing)
Read up on "backscatter spam".
This is a deliberate attack on your domain.
How it works:
A spammer uses infected home user boxes to send random mail to various
domains, with fake random addresses in your domain as the from or
reply-to address.When the target domain of the initial domain does not do recipient
validation at the smtp connection stage (as it should do), but spools
and then rejects the mail - to you, hence you are the real target.Greylisting is of no use whatsoever because the servers sending the
bounces to you are actual smtp boxes (sendmail, extrange, ....), not
malware, so they will quickly bypass spamd. Spamd greytraps will help a
great deal, but you say that the addresses are random.How to cope with it:
All you can do is make sure that you reject mail for unknown users at
the smtp connection stage. You can rate limit most mail daemons so they
don't overwhelm your box. Don't worry about it, I sometimes have up to
1300 messages a minute hitting my PII 350 box on a 500M ADSL and can not
tell the difference when surfing about.How to run a mailserver:
Reject mail for unknown users at the initial smtp connection stage.
For valid users; either reject spam at the smtp connection stage, or
spool it, process it later, tag it as spam and deliver it to the user's
spam box - do not bounce it later as you will then be generating
backscatter for some other poor soul.Note: some versions of exchange can not do recipient validation at the
smtp connection stage, so this will always be a problem, and is yet
another reason never to have exchange as an internet facing mail server.
I've snipped all the content (which I largely agree with) above and
below this paragraph to recount my experience which started about a
fortnight ago and ran for about a week.Log analysis showed that there were two classes of incoming unwanted
crap.One was bounced mail that should have been rejected as "invalid
recipient" mail at the original target. That included an mx at
aph.gov.au, the Australian Federal Parliamnet House. Yep, the pollies
who want ISPs to block websites on request and who spent $84mil on a
kiddie-filter that some 10-year old bypassed in ten minutes,The others were from bots as far as I could tell but they were not
being sent by MTAs which had received them.My defence was to write a couple of scripts. One parsed the output of
spamdb looking for GREY with sender <> and then tested the intended
recipient against the postfix valid mailbox database. If it failed then
the sender IP was added to a pf table that was outright blacklisted for
24 hours. The other script did housekeeping and added sender IPs to the
TRAPPED category in case they retried later.The blacklist grew rapidly to over 1200 unique addresses but then
petered out after a few days and I turned off the cron jobs running the
scripts at day nine.So greylisting/spamd did a hell of a good job for me. I would not have
been able to block traffic from all those crappily configured boxes
(MTAs mostly qmail or windows) unless I had a greylist database to scan
every few minutes.Peter H and Beck@ know what they are doing alright and do good papers
on it.
Thanks.
R/Me...a skeptic? I trust you have proof.
On 25 September 2007, RW <glisten@witworx.com> wrote:
[...]With Postfix you can use anvil(8) to control concurrency.
Regards,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
Yep, you could. BUT
1- why let it get to postfix? This is crap that spamd can deal with,
with a bit of scripting help for extra functionality.2- What concurrency?
We had a mailstorm of backscatter from hundreds of IPs each trying to
send one or two messages. We had over a thousand IPs marked TRAPPED in
spamdb at one time. Postfix would just be rejecting them and filling
its logs.As far as I'm concerned filling the logs of mailservers that are
backscatter generators is A Good Thing .In the beginning was The Word
and The Word was Content-type: text/plain
The Word of Rod.
What I've been seeing here the last few weeks is somewhat
different: robots trying to determine how many connections I'll accept
concurrently. Left alone they can get to 100+ connection attempts per
second from the same IP, they go on until I'm running out of resources
and start delaying the accept(2). When that happens, only one or two
of these connections are subsequently used to try to send the crap, the
rest are closed immediately. Limiting concurrency at SMTP level seems
to actually reduce the number of bots that try that (presumably the
information that my site is way too uninteresting is propagated across
the bot net).This has nothing to do with backscatter, but FWIW, backscatter alone
has never been a real problem with Postfix until recently. Resource
exhaustion because of insane concurrency as I described can be, and
anvil(8) is a first attempt to a solution (it's not THE solution becauseOh come on, these days you're probably rejecting > 95% of messages
Unfortunately the people in charge with these servers either don't
have a clue, or don't care.Regards,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
Nope. Every day at log reading time I do "grep reject maillog" and very
If even one sees a lot of greytrap try-again messages followed by an
entry when it gives up, then it will be worth it if it causes a config
to be fixed.
R/Me...a skeptic? I trust you have proof.
Yes, but the OPs problem is back scatter, and that does not come from
bots, they don't retry.$ man spamd:
DESCRIPTION
spamd is a fake sendmail(8)-like daemon which rejects false mail.
It is designed to be very efficient so that it does not slow down
the receiving machine.
..
..
greylisted hosts are redirected to spamd, but spamd has not yet
decided if they are likely spammers. They are given a temporary
failure message by spamd when they try to deliver mail.Greylisting works brilliantly for bots, but wont help with hosts that
retry, as is the case in back scatter.If the OP was repeatedly getting mail to a few addresses from different
hosts, he could use grey trapping. But he said that they are all random.
What I was getting looked like backscatter and smelled like backscatter
it is just that some of the IPs sending it didn't check out as MTAs.
i.e. they were not listed MXs for the domain they came from AND the
domain was not likely someone with separate outbound senders.They all retried too and when I had them as TRAPPED entries the logged
My experience entirely. I trapped them by looking for <> as sender,
parsing the recipient as invalid (using a postfix lookup) and then
inserting the IP into spamdb as TRAPPED.Later I firewalled them out for 24 hours. It cut the log clutter.
The scripts are still there but the crontab lines are commented out
until needed again.
R/A consultant is someone who's called in when someone has painted himself into a corner. He's expected to levitate his client out of that corner.
-The Sayings of Chairman Morrow. 1984.
'bots getting smart eh? Bugger! If that is the trend, greylisting starts
to lose its value as spammers adapt to the RFCs.Set up a pf queue of dialup speed for windows boxes connecting to port
25? Should slow them down a bit, but still let the odd legit extrange
sent mail in.
[...]
Greylisting is trivial to bypass, with or without a queue: just send
the same messages twice. Some spammers have figured that out long ago.
Ever wondered why sometimes you receive 2 or 3 copies of the same spam,
from the same IP, with the same Message-Id etc., a few minutes apart?Regards,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
That doesn't work, at least not against spamd.
How does spamd distinguish between a legitimate retry and a
re-injection of the same message with the same Message-Id, sender etc.?Regards,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
It can't.
But spamd's default of 25 minute "passtime" should help. (Well it does
help someone -- since it limits the spammer's resources.)(spamd doesn't know about Message-Id, it uses "connecting IP address,
HELO/EHLO, envelope-from, and envelope-to".)
It doesn't.
Just what you described would probably be within the default 25 mins
grey period. Another delivery attempt would be needed after this time to
pass spamd.
Why should it? The second copy is sent in a separate run, that's
the whole point. The only thing the bot has to figure out is how long
to wait until the second run. A smart one would send a second copyMoral: randomize the greylisting time...
Regards,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
On Wed, 26 Sep 2007 17:02:50 +0300
They would also need to use the same from address. If they randomly
choose from addresses, it wouldn't make any difference how often they
send the spam.I've seen numerous attempts to deliver the same message (presumably) to
the same recipient but with a different from address for each attempt.Eric Johnson
Or take advantage of the (by default) 25 minute window to use other
means to detect that this address is sending spam. Perhaps spamd should
be extended to look for excessive attempts to send messages from an
address during that period? (How often do spammers' lists contain only
one or two addresses from a domain?)Dave
--
Dave Anderson
<dave@daveanderson.com>
You could probably use straight rdr instead of rdr pass to feed spamd,
then in the relevant pass rule apply your source tracking options and
overload and some table magic for that--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Have you been looking at my ruleset? ;-)
I took out the pass on the rdr ages ago because unless I did my
personal blacklist could not be used to block things like stormers and
some tedious twits like a movie-house chain which keeps on sending to a
long gone client of mine even though the address returns a 554 every
time.I blacklist those permanently to stop log clutter.
Rod/
_____
Depressed? Me?
google: greyscanner
*BZZT!* Assuming facts not in evidence: a *smart* spambot /and/ a
Actually, the way it works is more like this:
1st try: 451 try again later
* At this point, anywhere between 80%-97% of spammers just move
on, there's millions more messages to spew out there, and
other hosts which are way more receptive.2nd try, after passtime: 451 try again later
(spamd to self: oh, this one retried, better whitelist)* This is where we decide it has a chance to be non-trash,
but we don't let on just yet3rd try: now you talk to the real smtp daemon (if there is one)
* They've passed the test. They may still be bastids, but
Random numbers can be fun, but I'd like to see real world data which
support your theory.I'm beginning to think that this is another one of those 'I refuse to
believe greylisting works because I refuse to understand it' episodes.--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
My point is it doesn't have to. The third copy passes regardless of
what happens with the first two.Ok, since you ask, here's a recent one. The message passed all my
filters, so it was received three times. Please note the identical
message-id.First run:
Sep 25 18:06:16 ns1 postfix-localhost/smtpd[27143]: 9FAE1142A7: client=unknown[212.239.40.101]
Sep 25 18:06:17 ns1 postfix/cleanup[3734]: 9FAE1142A7: message-id=<20070925150257.7239.qmail@web05.aziendeitalia.com>
Sep 25 18:06:18 ns1 postfix/qmgr[1554]: 9FAE1142A7: from=<root@web05.aziendeitalia.com>, size=2545, nrcpt=2 (queue active)
Sep 25 18:06:18 ns1 postfix/pipe[25075]: 9FAE1142A7: to=<daia@euler.imar.ro>, relay=uucpz, delay=1.8, delays=1.7/0/0/0.06, dsn=2.0.0, status=sent (delivered via uucpz service)
Sep 25 18:06:18 ns1 postfix/local[7260]: 9FAE1142A7: to=<gather_stats@localhost.imar.ro>, relay=local, delay=1.9, delays=1.7/0/0/0.24, dsn=2.0.0, status=sent (delivered to command: /usr/local/sbin/gather_stats.pl /usr/local/share/Mail_stats)
Sep 25 18:06:18 ns1 postfix/qmgr[1554]: 9FAE1142A7: removedThe same message, sent 8 minutes later:
Sep 25 18:14:14 ns1 postfix-localhost/smtpd[8404]: 1649714331: client=unknown[212.239.40.101]
Sep 25 18:14:15 ns1 postfix/cleanup[21622]: 1649714331: message-id=<20070925150257.7239.qmail@web05.aziendeitalia.com>
Sep 25 18:14:15 ns1 postfix/qmgr[1554]: 1649714331: from=<root@web05.aziendeitalia.com>, size=2547, nrcpt=2 (queue active)
Sep 25 18:14:15 ns1 postfix/pipe[25075]: 1649714331: to=<daia@euler.imar.ro>, relay=uucpz, delay=1.4, delays=1.4/0/0/0.05, dsn=2.0.0, status=sent (delivered via uucpz service)
Sep 25 18:14:15 ns1 postfix/local[7260]: 1649714331: to=<gather_stats@localhost.imar.ro>, relay=local, delay=1.6, delays=1.4/0/0/0.25, dsn=2.0.0, status=sent (delivered to command: /usr/local/sbin/gather_stats.pl /usr/local/share/Mail_stats)
Sep 25 18:14:15 ns1 postfix/qmgr[1554]: 1649714331: removedSame, 28 minutes ...
Just to give an additional data point here: I work for an ISP that
receives upwards of a million inbound SMTP connections per day.While watching the connection logs, I've noticed that a large majority
of spammers get the first spamd response ("250 Hello, spam sender.
Pleased to be wasting your time.") and immediately disconnect. This
suggests to me that rather than spend time trying to get whitelisted
by spamd servers, they've mostly decided to skip them entirely and
move on to servers that aren't running spamd.Spamd, by itself, filters out almost 90% of our inbound email. So far,
I've had just two false positives from mail servers that weren't
behaving correctly, that I had to whitelist manually.We're running spamd with its defaults, for now.
spamd doesn't catch everything, but "it works" is a bit of an understatement.
We've also been hit by backscatter, and I haven't had the time to
figure out how to stop that one yet.- R.
Hi!
Interesting. Do you think they pattern match on the response, or do you
think they disconnect if the initial greeting takes too long (spamd
"stutters" for the first 10 seconds, in its default settings)? I'd guessFor some, signed envelope senders or variations thereof work. That
depends on a few circumstances.The basic idea is this:
My email address is hannah@schlund.de. Normal mail installations would
send mails out with both the From header *and* the envelope sender set
to hannah@schlund.de. SES and similar schemes instead create a modified
sender address like TAG+hannah+timestamp+sig@schlund.de. That is used
in the envelope. The header From address is left unmodified. "TAG" is a
tag saying "this is a address created using the envelope signing
scheme", hannah is the original local part, timestamp can be made short
by making it have only day granularity, and perhaps even only days
modulo 2^.... sig is a MAC, created from the local part, the timestamp
and a host specific key.When a legitimate bounce (empty envelope from) is received, it must be
in response to a mail recently sent out from our domain. If all mails
sent out from our domain use the envelope signing scheme, bounces need
only be accepted if they are to *signed* addresses that are recent
enough and have a valid MAC. Bounces that don't fulfill that can be
rejected (I'd reject after DATA or later so address verification will
not lead to false positive rejects in other situations). In addition,
bounces should be only addressed to exactly *one* recipient...Some also use SRS (sender rewriting scheme, from the SPF people),
signing their own envelope as if the mail were forwarded, and acceptKind regards,
Hannah.
Hannah,
I would guess the latter too, except that they tend to wait the full
default 10 seconds until the first 250 response. I'm looking forward
to increasing the stutter time to something on the order of 60 seconds[...snip...]
That would be nifty, but I don't think it would work in our case. We
have a number of customers that send mail through their own mail
server (or another provider's mail server) and receive mail through
ours (old email addresses, hosted domains, etc.).So far we've seen the backscatter come through in a quick burst from a
handful of mail servers. For one example, one of our unlucky users
received 800+ bounce messages from about four mail servers in Italy. I
think I can use max-src-conn and max-src-conn-rate, plus a few
whitelist entries for Google, Yahoo, etc., to stop that, but it
requires careful monitoring.- R.
I have reports that increasing the -s value to 4 seconds serves to
keep the stupid ones around for (you guessed it) four times as long,
at least for the tarpitted ones. So the host which would hang on for
404 seconds earlier now beavers on for 1616, and so on.- P
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Not good example. As that would still hit spamd (default 25 minutes and
your earlier one was too fast). Now it is whitelisted.Do you have a fourth email sent? (Which will have passed.)
Not at hand, but I haven't been looking for one either. Does spamd
really behave like that? That is, ignore retries during the greylisting
period, and whitelist messages only on subsequent attempts?Regards,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
greylisting does what it does. It delays the initial email
for 30 minutes or more. what you do with that 30 minutes will decide
on how effective it is for you.In that 30 minutes)
1) you can look at their traffic profile and decide you don't want to
talk to them.2) they can hit a greytrap locally and you can decide you don't want to
talk to them.3) they can hit a bogus domain mx'ed to you locally and you can decide you
don't want to talk to them.4) optionally, if you check the greylist against valid local mail addresses,
you could trap them if they're mailing to bogus local addresses (we do that here)5) 1-4 could happen above at someone elses site (like nixspam or uatraps) that
you are using as a blacklist.And in the end some of it gets through. That's why you run other
stuff in addition to spamd if you really can't stand that.spamd is designed to get the low hanging fruit. It is *NOT* designed
to stop all possible spam, forever. attempting to do so there is wrong. Spamd is
a *tool* - it's good for what it's good for - stopping stuff that is easily
identifiable in the smtp dialogue. It is not intended for other things.-Bob
--- Bob Beck <beck@bofh.cns.ualberta.ca> wrote:
Is there a standard way to achieve that or does one just hack a shell
script together?// juan
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca
Yes, there are some standard ways as documented in spamd(8)- they are
relatively new, so if your spamd is old you don't have them. see
the /etc/mail/spamd/alloweddomains, etc. etc.There is a quasi standard perl script which I have posted and is available
frequently referenced in the archives of this list, and has already been mentioned
twice in this thread. it is not "standard" with OpenBSD because pieces of it
must be customized to be site specific, so it's not really a generic solution, but
it can do some things the generic stuff can't.-Bob
And that script works quite well, I can report. Heck, even not using
the user validation parts it cuts a lot of crud out. (And by a lot, I
mean a lot of what just spamd doesn't grab...).--Kurt
[...]
Ok, brain dump:
That's an interesting idea, a lot of slow operations could be
offloaded to those 30 minutes. Your greyscanner script does DNS checks
on the envelope. A lot more could be done, should the script have
access to the body. I think it's legal to reply with 4xx (that is,
simulate a queue error) to the final "." . That could be used to gather
and inspect the data; basically do at greylisting time what Postfix does
with the "after-queue filters".I suppose gathering everything would be prohibitive though, and
against the entire philosophy of greylisting. Which brings me to a
different approach: use a "pre-queue filter" instead of spamd (which is
what I'm doing now). Now, the problem with pre-queue filters is they
can take too long to scan a message. Thus, the better mouse trap: a
pre-queue filter, which can send feedback to smapd, and use spamd's
database to keep some state across messages. I need to ponder on thatWe are in violent agreement here...
Regards,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
OK, but you did say "a few minutes apart".
In English, few is normally a single digit.
Between which min/max valuse? Keep in mind that this corresponds to the
(minimum) delay introduced in delivering a good messages to the mailbox.ciao
Luca
That's up to you. The minimum should be large enough to keep away
"naive" bots, as it does now. The maximum should be as large as you
can afford without being too anti-social. :) Some crap will still pass
through anyway.Regards,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
Sometimes is not about being social, but about receiving important
messages in time. Some greylisting implementations have a bit more
relaxed policies on whitelisting (e.g. whitelisting /24 subnets on which
the sender resides instead of single IP address) to speed up
whitelisting efficiency. Not sure about how much spam this allows to
slip through.ciao
Luca
The maximum should also leave plenty of time before expiry. Some
mailers use queue backoff algorithms, which means some legitimate
messages might never get a chance to pass if the window is too small...Regards,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
The defaults work very well:
See: http://www.ualberta.ca/~beck/nycbug06/spamd/mgp00001.html
Hear: http://www.fetissov.org/public/nycbsdcon06/2.4.mp3
Maybe this also has to do with amount and type of traffic you get.
Small shops are probably more likely to experience delays, while hosters
of a large number of high traffic domains should have whitelists converge fast.ciao
Luca
If they adapt to greylisting and start following relevant RFCs, we've
succeeded in making spamming more expensive. I don't see that
happening much, though. The spam that reaches content filtering here
has managed to get itself into the queue on real mail servers which
for some reason allows them.On the 'spamd looks like an open relay' issue, it would make sense to
use a relay checker which actually checks for mail received, not just
the status codes. On the other hand I actually like that part of
spamd the way it is. Spammers who apparently think every IP address
in our range is an open relay occasionally swell our greylists quite a
bit. None of it ever gets delivered, of course, but we see the
attempts quite often these days.--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
You did buy a nice frame to put that in, I hope? ;)
I've been noticing that the generated junk addresses which were
originally used as from addresses on spam sent to elsewhere
(generating the bounces we see here) tend to resurface pretty soon in
my greylists as to addresses on attempted incoming spam. I also see
quite a few attempts at reaching actually deliverable addresses in our
domains with a fake from address. So I think it may be just a matter
of time before I see spam where both to and from are already in my
spamtraps.(and thanks, RW)
- P
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
I think what happened here is that somebody let the random address
generator run for longer than intended.One or more spammer groups has been doing similar things to some of
the domains I admin for some months now, and the typical rate of new,
essentially random, addresses found per day is about 20, sometimes as
high as 50, and in one case more than 700. That last one was probably
a case of asleep at the wheel too.--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
The real question in there is, what does a properly configured mail
server do with spam? My answer is, if it gets as far as content
filtering, drop it as soon as it's classified as spam, don't bounce
it. Bouncing spam is never useful, the purported return address is
extremely unlikely to be deliverable.A bounce is only useful for valid messages (which happen to be sent to
a mistyped address), which in our context means that the message has
passed greylisting and most likely some content filtering or other.
In all likelihood you will still bounce to a few bogus ones, but
taking this approach makes you a lot less noisy.The noise you are seeing is from sites which either don't bother much
with filtering, or if they do, belong to that little cult of "bouncingUnless your spamd box is extremely skinny, none of these figures are
particularly worrying. spamd allocates IIRC about 12 kilobytes of
buffers per tarpitted host, for greylist entries just another tuple in
the database.My list of trap addresses, all harvested from stuff from out there, is
just over 2700. Right now there are 273 hosts in the greylist at the
gateway closest to where I'm sitting (my home net, actually), with 533Well, it should not be a huge problem. IMO people who fake addresses
in other people's domains should be prosecuted for some variety of
fraud, but with the current level of digital competence in law
enforcement that is just not going to happen. In the meantime we have
reasonable countermeasures. See what greyscanner can do for you.- P
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
I've seen something *very* similar. In my case the "user" portions
seemed random at first glance, but some were repeated a LOT. See if you
have that, too. If so, enter those "random" addresses as SPAMTRAP
entries. That way they're blocked for 24 hours, and will reblock
themselves if they persist.I had also done a log tailer that added to a blacklist, but that turned
out not to be needed with the above. ymmv.--
Darrin Chandler | Phoenix BSD User Group | MetaBUG
dwchandler@stilyagin.com | http://phxbug.org/ | http://metabug.org/
http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
They seemed pretty random to me, but I did a quick
check after reading your response and I see 468 unique
"fake" email address @my-domain, only one was
duplicated twice.This was in the span of about 1 hour, from 13:38 to 14:31
Pacific time. After which I enabled filtering of SMTP port
'til I figure out what I am going to do.I can't imagine entering all those address as spamtraps.
Another user suggested greytrapping in private email,
which made me reread spamd(8) a couple of times, at
least the 'GREYTRAPPING' section, which mentions
/etc/mail/spamd.alloweddomains file. It doesn't specifically
say one could use it to enter valid email address in that
file, but a naive look at the source spamd/grey.c suggests
it could work. I plan on giving this a try unless someone
from the list advises against it.Is there anyway one could flush the GREY entries from
spamdb? I had the problem where I would clear the WHITE
entries that didn't belong, but the WHITE list would grow
rapidly out of control again.I'm not sure if this is related or not, but I have noticed
that a few times yesterday and once again tonight around 8PM
PDT, spamd-setup failed on ftp with "connection time out".--
"How romantic. Two lovers' first kiss shared on
the banks of the river Seine" -- LL as CK (ep.72 s04e06)
What's the problem, they'll just be dropped "user unknown"
by your MTA won't they?
It wouldn't be a problem if it didn't mimic a DDOS attack.
Getting bombarded by many dozen SMTP connection in a very
short time-span iss a bit alarming (at least was to me).Other than that, I agree, sendmail would drop them as "User
unknown" and that's the end of story.Btw, your "reply-to" field contains my e-mail address. Is that
intended?Cheers,
--patrick
If it's compatible with how you use the domain, it might help
The correct behaviour is to reject it at the SMTP port, rather
than issue a bounce.Also: all hosts listed in MX records should be aware of the
list of valid users and do the same. For sendmail, this is easyThese are bounces, so they'll be coming from MTAs with retry
queues, so they generally will make it through to the real MTA
after (a minimum of) 3 retry attempts.Depending on how many "normal" spams that spamd saves you
from, it may be a hindrance to use greylisting here. It might
be better just to get these mails handled quickly and out of
the sender's queues (depends on your bandwidth situation).Mail-Followup-To, actually - yes. It wouldn't totally surprise
me if gmail is doing something unexpected with it, though (-:
I had a question off-list about how to do this, so I guess
some other people will benefit from an example of how to set
this up.To:domain.com error:550 5.1.1 No such user
To:postmaster@domain.com OK
To:user1@domain.com OK
To:user2@domain.com OKthen (cd /etc/mail; sudo makemap hash access < access)
If you are using postfix:
/etc/postfix/main.cf:
..
..
smtpd_recipient_restrictions =
reject_non_fqdn_hostname
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unlisted_recipient <-- this one
reject_unlisted_sender
reject_unknown_reverse_client_hostname
warn_if_reject reject_unknown_client_hostname
reject_unknown_helo_hostname
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
...
...
...
unknown_address_reject_code = 554
alias_maps = btree:$config_directory/aliases/etc/postfix/aliases:
..
..
joe.bloggs jb123456
joe jb123456
bloggs jb123456$ sudo postfix reload
Isn't this actually a postfix default?
As smtpd_reject_unlisted_recipient defaults to yes.--
Chris
Absolutely correct, but by poking it in smtpd_recipient_restrictions you
can choose when to invoke it. Probably makes little difference either
way in the real world.
I suppose I'll never know how many receivers of spam claiming to be
from 13RDETTIWT2@datadok.no (yes, fresh from the source) and friends
actually acted on the SPF info for the domain and skipped sending a
bounce, but the ones that don't use SPF in any meaningful way still
generate significant backscatter. Once 13RDETTIWT2@datadok.no is a
spamtrap it won't matter much of course, except for any valid mail
which might happen to venture out from the same IP address to somebody
at datadok.no.--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Put greyscanner from Bob in there and sit back and enjoy the look! (;>
Make sure you pick the version for your OS however. 4.0 and below oppose
to 4.1.It will take care of that in a hart beat!
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Nicolas Pitre | Re: [RFC patch 08/18] cnt32_to_63 should use smp_rmb() |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Natalie Protasevich | [BUG] New Kernel Bugs |
