On 11 Jul 2014, at 16:16, D'Arcy J.M. Cain wrote:
On Fri, 11 Jul 2014 21:06:59 +0200
"li...@rhsoft.net" <li...@rhsoft.net> wrote:
this message in at least three scenarios that I can see. One,
someone sends email to an invalid address and we reject the balance
of the session. Two, we reject the session because of an RBL.
Three, someone is probing to find out if an address is valid. I
you did not provide any log but "lost connection after RCPT"
means the client did not quit the smtp session properly and
so the client is broken
Are you sure that you read my message? That's only one of the three
scenarios that generates that log.
* client connects
* client send SMTP commands
* postfix answers with the REJECT status
* client blindly closes the connection
That's number one above.
No, it seems to be a generic description of all 3 scenarios you
describe.
The most common modern configuration of Postfix postpones policy-based
rejections for reasons that are determined early in the SMTP
conversation until the RCPT command, because historically some sending
software (even some which was nominally legitimate, e.g. Exchange,
qmail) reacted in undesirable ways to 5xx replies to earlier commands.
"Rejection" in all 3 of your scenarios is a 5xx reply code from Postfix
to the client's RCPT command.
The formally proper reactions by a well-behaved SMTP client to that
event do not include unilaterally closing the TCP connection over which
the SMTP session is running. The proper way to end an SMTP session is to
send the QUIT command and await the inevitable 221 reply and
server-initiated TCP closure, but many spammer tools (and a few MUA's)
either never send the QUIT or send it with a TCP FIN flag of their own
and immediately dispose of their end of the connection. That event is
logged by Postfix as a "lost connection after RCPT" because that is what
it is. A proper client could also have offered another RCPT or RSET
followed by a new transaction.
The problem is that Postfix logs the same
message for scenario number three which is the one I want to isolate.
Scenario 3 is indistinguishable from Scenario 1. The only useful means
in the modern world to probe the validity of u...@example.com requires
the prober to say "RCPT TO:<u...@example.com>" to an MX for example.com
(after suitable HELO/EHLO & MAIL commands) and check the reply code. A
definitive test also requires following through with an actual message
if the reply to RCPT begins with '250' and then waiting for a true reply
to the message, but most spam facilitators will just check the RCPT
reply code and move to the next address in their list.
Actually, number three can also look like number one when they try an
invalid address so grepping for the lost connection log line would be
fine if I could ignore number two.
You're looking for a solution in the wrong place. Postfix logs its
rejections of RCPT commands clearly in lines that include the envelope
sender, rejected recipient, ehlo/helo argument, connecting IP/hostname,
and the specific reply code & text that it gave to the client. For
example, here are 4 rejections by my server today, selected for their
lack of obscenity in response text and very lightly redacted, showing 4
different types of rejection including those you want to identify. Note:
I have "smtpd_delay_open_until_valid_rcpt = no" & "enable_long_queue_ids
= yes" so these have nice long meaningful and eternally unique IDs where
your logs might have NOQUEUE or shorter traditional Postfix IDs:
Fri Jul 11 16:13:46 toaster postfix/smtpd[44274]: 3h956y3tPTz1XtSCD:
reject: RCPT from drone13.ral.icpbounce.com[66.192.165.132]: 550 5.7.1
<bounces+630579.127201093.883...@icpbounce.com>: Sender address
rejected: Too much spam from your ESP.;
from=<bounces+630579.127201093.883...@icpbounce.com>
to=<red...@billmail.scconsult.com> proto=ESMTP
helo=<drone13.ral.icpbounce.com>
Fri Jul 11 16:14:19 toaster postfix/smtpd[44274]: 3h957b4lzFz1XtSCJ:
reject: RCPT from unknown[87.252.208.73]: 550 5.7.1
<kwame_ak...@yahoo.com.ph>: Sender address rejected: Mail from Yahoo's
sewer is not welcome here. Get a real mail service.;
from=<kwame_ak...@yahoo.com.ph> to=<red...@scconsult.com> proto=ESMTP
helo=<researchandmarkets.org>
Both of those are due to local check_sender_access rules.
Fri Jul 11 18:05:22 toaster postfix/smtpd[45421]: 3h97bj3k7fz1XtSJP:
reject: RCPT from unknown[85.237.53.92]: 554 5.7.1 Service unavailable;
Client host [85.237.53.92] blocked using psbl.surriel.com; Listed in
PSBL, see http://psbl.org/listing?ip=85.237.53.92; from=<i...@pekof.com>
to=<red...@scconsult.com> proto=ESMTP helo=<mail.pekof.com>
A DNSBL rejection.
Fri Jul 11 18:34:13 toaster postfix/smtpd[45719]: 3h98Dz6dv0z1XtSLG:
reject: RCPT from vds1-14.ispfr.net[195.14.0.23]: 550 5.1.1
<ad...@scconsult.com>: Recipient address rejected: User unknown in relay
recipient table; from=<red...@rachatde-credits.fr>
to=<ad...@scconsult.com> proto=ESMTP helo=<de505.ispfr.net>
A spammer trying to mail or verify a bogus address.
