Noel Jones:
[ Charset ISO-8859-1 converted... ]
> On 7/11/2014 3:16 PM, 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.
>
> But there's really only one scenario. The only time postfix logs
> that message is when the connection is lost after RCPT. This is
> always caused by either A) a poorly written mail engine that
> improperly drops the connection, or B) a network problem.
> Unfortunately, it's impossible to tell the difference from your end.
> All postfix knows is the connection was lost unexpectedly, and it
> would be improper to not log it.
>
> You're focusing on what happens before the lost connection. That's a
> job for log analysis tools.
>
> I suppose the "recipient count" could be added to the "lost
> connection" message. That might be modestly useful to the general
> user base. Maybe something like:
>
> postfix/smtpd[nnn]: lost connection after RCPT from
> test.example.com[192.0.2.100], nrcpt=N
>
> But that's just an idea, not a fully thought-out proposal. Feel free
> to submit a patch.
I wonder, does that include rejected recipients? What about recipients
in earlier transactions within the same SMTP session? Whatever we
log would need to be easy to explain.
Wietse
> Of course, the spamware writers could easily fix this little
> artifact by sending QUIT after their payload is rejected rather than
> just dropping the connection. They already know this. Apparently
> (for now) they would rather save a few milliseconds and move on to
> the next target.
>
>
>
>
> -- Noel Jones
>
