On Mon, 6 Jun 2005, Alexander Zangerl wrote:
> the greet_pause feature works fine on "real" connections, that is
> whenever the sending side does elicit to talk to you.
Good :)
> in the case of a sender connecting to your smtp port, then closing
> the connection before a single byte of data has been exchanged,
> greet_pause misfires.
Interesting, the greet-code is only supposed to fire if there is
data on fd. It may be that the early close effectively sets an EOF
or error condition on the stream.
> as the connection in question is already being closed, the problem
> is mainly the nuisance of lots of log entries.
It'd be nice if you included some of those log entries !
I'd also expect to see something along the lines of:
... did not issue MAIL/EXPN/VRFY/ETRN during connection to ...
in your log for this connection
I get alot of the these messages because of nagios - kind of a pita,
but something I'm willing to live with for notification nagios provides.
> i'm attaching a tcpdump of one such connection.
> 193.154.160.103 is a queuing box that tries to verify my box's liveness
> (that's 193.154.164.188) and which does not always wait with shutting down
> until the smtp greeting is displayed.
> greet_pause misfiring means that after the fin is received and acked by
> my box, my box sends an unnecessary 554 not accepting messages, and logs
> the perceived badness of the other party.
Please provide some data from /var/log{,/mail}/mail.log showing all the
messages for one of these connections.
I can the forward the information upstream - to see if/how they'd like
to approach the issue.
At first blush, for my money, you're not playing nice with sendmail -
even the nagios sendmail plugin gets this right... while the 554
shouldn't be delivered, this would be a fairly low priority item for
me to create a patch for.
--
Rick Nelson
<kceee^> I hate users
<knghtbrd> you sound like a sysadmin already!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
