On Wed, 26 Sep 2007 17:02:50 +0300
Liviu Daia [EMAIL PROTECTED] wrote:
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 copy
after 10
--- Bob Beck [EMAIL PROTECTED] wrote:
[snip]
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)
[snip]
4) optionally, if you check the greylist
* Juan Miscaro [EMAIL PROTECTED] [2007-09-27 11:36]:
--- Bob Beck [EMAIL PROTECTED] wrote:
[snip]
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
Bob Beck wrote:
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
Chris Smith wrote:
On Tuesday 25 September 2007, Craig Skinner wrote:
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
RW wrote:
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
Craig Skinner [EMAIL PROTECTED] writes:
'bots getting smart eh? Bugger! If that is the trend, greylisting
starts to lose its value as spammers adapt to the RFCs.
If they adapt to greylisting and start following relevant RFCs, we've
succeeded in making spamming more expensive. I don't see that
On 26 September 2007, Craig Skinner [EMAIL PROTECTED] wrote:
RW wrote:
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
On Wed, 26 Sep 2007, Liviu Daia wrote:
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
On 26 September 2007, Damien Miller [EMAIL PROTECTED] wrote:
On Wed, 26 Sep 2007, Liviu Daia wrote:
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
Liviu Daia wrote:
How does spamd distinguish between a legitimate retry and a
re-injection of the same message with the same Message-Id, sender etc.?
It doesn't.
Just what you described would probably be within the default 25 mins
grey period. Another delivery attempt would be needed
On Wed, 26 Sep 2007, Liviu Daia wrote:
On 26 September 2007, Damien Miller [EMAIL PROTECTED] wrote:
On Wed, 26 Sep 2007, Liviu Daia wrote:
Greylisting is trivial to bypass, with or without a queue: just
send the same messages twice. Some spammers have figured that out
long ago.
On 26 September 2007, Craig Skinner [EMAIL PROTECTED] wrote:
Liviu Daia wrote:
How does spamd distinguish between a legitimate retry and a
re-injection of the same message with the same Message-Id, sender
etc.?
It doesn't.
Just what you described would probably be within the
On Wed, 2007-09-26 at 17:02 +0300, Liviu Daia wrote:
Another delivery attempt would be needed after this time to pass
spamd.
Moral: randomize the greylisting time...
Between which min/max valuse? Keep in mind that this corresponds to the
(minimum) delay introduced in delivering a good
Liviu Daia wrote:
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 copy
after 10 minutes, and a third one after, say, 35 minutes.
OK, but
On 26 September 2007, Luca Corti [EMAIL PROTECTED] wrote:
On Wed, 2007-09-26 at 17:02 +0300, Liviu Daia wrote:
Another delivery attempt would be needed after this time to pass
spamd.
Moral: randomize the greylisting time...
Between which min/max valuse? Keep in mind that this
On 26 September 2007, Liviu Daia [EMAIL PROTECTED] wrote:
On 26 September 2007, Luca Corti [EMAIL PROTECTED] wrote:
On Wed, 2007-09-26 at 17:02 +0300, Liviu Daia wrote:
Another delivery attempt would be needed after this time to pass
spamd.
Moral: randomize the greylisting
Liviu Daia [EMAIL PROTECTED] writes:
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 copy
after 10 minutes, and a third one after, say,
Liviu Daia wrote:
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.
The maximum should also leave plenty of time
On Wed, 26 Sep 2007, Liviu Daia wrote:
On 26 September 2007, Craig Skinner [EMAIL PROTECTED] wrote:
Liviu Daia wrote:
How does spamd distinguish between a legitimate retry and a
re-injection of the same message with the same Message-Id, sender
etc.?
It doesn't.
Just what you
On 2007/09/26 11:03, Dave Anderson wrote:
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?
google:
Dave Anderson [EMAIL PROTECTED] writes:
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
On Wed, 2007-09-26 at 17:38 +0300, Liviu Daia wrote:
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.
Sometimes is
On Wed, 2007-09-26 at 16:01 +0100, Craig Skinner wrote:
The defaults work very well:
See: http://www.ualberta.ca/~beck/nycbug06/spamd/mgp1.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
On 26 September 2007, Peter N. M. Hansteen [EMAIL PROTECTED] wrote:
Liviu Daia [EMAIL PROTECTED] writes:
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
Oh, I'm not saying it doesn't work. What I'm saying is, greylisting
is trivial to bypass, and some spammers have figured that out.
Amazingly, most of them still haven't, which is why it still works in a
significant number of cases.
greylisting does what it does. It delays the
On Wed, 26 Sep 2007, Liviu Daia wrote:
Same, 28 minutes later:
Sep 25 18:42:52 ns1 postfix-localhost/smtpd[13055]: 72BCD142A7:
client=unknown[212.239.40.101]
Sep 25 18:42:53 ns1 postfix/cleanup[21622]: 72BCD142A7: message-id=[EMAIL
PROTECTED]
Sep 25 18:42:53 ns1 postfix/qmgr[1554]:
On 26 September 2007, Jeremy C. Reed [EMAIL PROTECTED] wrote:
On Wed, 26 Sep 2007, Liviu Daia wrote:
Same, 28 minutes later:
Sep 25 18:42:52 ns1 postfix-localhost/smtpd[13055]: 72BCD142A7:
client=unknown[212.239.40.101]
Sep 25 18:42:53 ns1 postfix/cleanup[21622]: 72BCD142A7:
On 26 September 2007, Bob Beck [EMAIL PROTECTED] wrote:
Oh, I'm not saying it doesn't work. What I'm saying is,
greylisting is trivial to bypass, and some spammers have figured
that out. Amazingly, most of them still haven't, which is why it
still works in a significant number of
Oh, I'm not saying it doesn't work. What I'm saying is, greylisting
is trivial to bypass, and some spammers have figured that out.
Amazingly, most of them still haven't, which is why it still works in a
significant number of cases.
Just to give an additional data point here: I work for
Hi!
On Wed, Sep 26, 2007 at 02:03:03PM -0700, Rob wrote:
[...]
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
Hannah,
On 9/26/07, Hannah Schroeter [EMAIL PROTECTED] wrote:
Hi!
On Wed, Sep 26, 2007 at 02:03:03PM -0700, Rob wrote:
[...]
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
Rob [EMAIL PROTECTED] writes:
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
and watching to see what happens then.
I have reports
On Wed, 26 Sep 2007 17:26:22 +0200, Peter N. M. Hansteen wrote:
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
On 9/23/07, Peter N. M. Hansteen [EMAIL PROTECTED] wrote:
patrick keshishian [EMAIL PROTECTED] writes:
I'm running spamdb in greylist mode, but these servers were
getting white-listed very quickly.
Then it sounds almost like you were running with a too short passtime,
but then that's easy
patrick keshishian [EMAIL PROTECTED] writes:
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?
The real question in there is, what does a properly configured mail
patrick keshishian wrote:
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
Craig Skinner [EMAIL PROTECTED] writes:
malware, so they will quickly bypass spamd. Spamd greytraps will help
a great deal, but you say that the addresses are random.
I think what happened here is that somebody let the random address
generator run for longer than intended.
One or more
On 2007/09/25 00:08, patrick keshishian wrote:
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
Stuart Henderson [EMAIL PROTECTED] writes:
If it's compatible with how you use the domain, it might help
to publish SPF records.
I suppose I'll never know how many receivers of spam claiming to be
from [EMAIL PROTECTED] (yes, fresh from the source) and friends
actually acted on the SPF info
On 2007/09/25 10:29, Stuart Henderson wrote:
Also: all hosts listed in MX records should be aware of the
list of valid users and do the same. For sendmail, this is easy
to do with the access map.
I had a question off-list about how to do this, so I guess
some other people will benefit from an
On Tue, 25 Sep 2007 09:38:10 +0100, Craig Skinner wrote:
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
RW [EMAIL PROTECTED] writes:
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
Stuart Henderson wrote:
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.
If you are using postfix:
/etc/postfix/main.cf:
..
..
smtpd_recipient_restrictions =
reject_non_fqdn_hostname
RW wrote:
The others were from bots as far as I could tell but they were not
being sent by MTAs which had received them.
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
On 25 September 2007, RW [EMAIL PROTECTED] wrote:
[...]
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.
[...]
With Postfix you can use anvil(8) to
On Tuesday 25 September 2007, Craig Skinner wrote:
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
On Tue, 25 Sep 2007 12:40:50 +0100, Craig Skinner wrote:
RW wrote:
The others were from bots as far as I could tell but they were not
being sent by MTAs which had received them.
Yes, but the OPs problem is back scatter, and that does not come from
bots, they don't retry.
What I was
On Tue, 25 Sep 2007 14:14:46 +0300, Liviu Daia wrote:
On 25 September 2007, RW [EMAIL PROTECTED] wrote:
[...]
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
On 26 September 2007, RW [EMAIL PROTECTED] wrote:
On Tue, 25 Sep 2007 14:14:46 +0300, Liviu Daia wrote:
On 25 September 2007, RW [EMAIL PROTECTED] wrote:
[...]
My defence was to write a couple of scripts. One parsed the output
of spamdb looking for GREY with sender and then tested the
On Wed, 26 Sep 2007 03:16:35 +0300, Liviu Daia wrote:
Postfix would just be rejecting them and filling its logs.
Oh come on, these days you're probably rejecting 95% of messages
anyway. :)
Nope. Every day at log reading time I do grep reject maillog and very
rarely do I see a result.
On 2007/09/23 20:53, patrick keshishian wrote:
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.
What's the problem, they'll just be dropped user unknown
by your MTA won't
On 9/24/07, Stuart Henderson [EMAIL PROTECTED] wrote:
On 2007/09/23 20:53, patrick keshishian wrote:
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.
What's the
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 |
On Sun, Sep 23, 2007 at 03:33:03PM -0700, patrick keshishian wrote:
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
On 9/23/07, Darrin Chandler [EMAIL PROTECTED] wrote:
On Sun, Sep 23, 2007 at 03:33:03PM -0700, patrick keshishian wrote:
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.
patrick keshishian wrote:
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.
Put greyscanner from Bob in there and sit back and enjoy the look! (;
Make sure you pick the
patrick keshishian [EMAIL PROTECTED] writes:
I'm running spamdb in greylist mode, but these servers were
getting white-listed very quickly.
Then it sounds almost like you were running with a too short passtime,
but then that's easy to adjust.
At around 1:40 PM (PDT) my SMTP server started
58 matches
Mail list logo
