Rocco Scappatura wrote:
% telnet yourserver 25
...
EHLO somehostname
...
MAIL FROM:<sender>
...
RCPT TO:<recipient>
DATA
copy-patse the message with full headers except the Delivered-To that
contains your recipient address
end with a line containing a dot ('.') like this:
.
QUIT
Infact I get:
Feb 26 23:07:50 av4 amavis[17589]: (17589-03) Blocked SPAM,
[<ipofmyserver>] [<ipofmyserver>] <[EMAIL PROTECTED]> -> <<myemailaddress>>,
quarantine: r/spam-rGPEbZ4mzhH4.gz, Message-ID:
<[EMAIL PROTECTED]>, mail_id: rGPEbZ4mzhH4, Hits: 7.193,
size: 4063, 1874 ms
And spammer are becoming more faster as the time goes on.. Is it
convenient to use gray listing
newer bots retry, so GL is only effective is the time interval is large
enough, but that's not a neutral thing so should be restricted to
suspicious mail. That's what I use GL for anyway.
or there is something other effective
tecnique that I could use to reduce false negative?
Thanks,
rocsca
the spam you showed has:
Received: from [125.128.59.158] (unknown [125.128.59.158])
which means the client is "unknown" and it helo'ed with a literal IP
(it's from Korea too but let's ignore this). My postfix has a
check_helo_acces with a pcre:
/^[/ reject_unknown_client, policy_greylist
This rejects mail if the client is unknown and helo's with a literal IP.
I've not seen literal IPs in ham on an MX. Note that this test must not
be applied on an MSA: MUAs like Thunderbird do helo with a literal IP.
The test is run before DNSBL checks, so it saves some cycles and reduces
the load on DNSBL sites. these days, the test catches about 15% of mail
rejected at MTA time.
Note that reject_unknown_client returns a temp error, but unlike GL,
you'll need to whitelist the client if you want to accept his mail). if
this is a real issue, just remove the reject_unknown_client part and
leave the greylisting check. but
of course, this is mostly a temporary cure. if ratware learns to helo
with a hostname, it won't be caught. but let's fight the spam of today
for now ;-p
